Loading Worker Using H CM Data Loader

Loading Worker
Using HCM Data Loader V1.4
Oracle Fusion Human Capital Management 11g Release 9 (11.1.9)

ORACLE WHITE PAPER | MARCH 2017
Table of Contents
Introduction 1
How to Use the Information in This Document 1
Example Dat Files 2
Change Log 2
Worker 3
Considerations and Prerequisites for Worker 3
Person 3
Oracle Fusion Human Capital Management Employment Model Overview 4
Configuration of the Employment Model 5
Actions / Action Reasons Framework 7
Person Types 7
Assignment Status Types 8
Earliest Effective Start and Last Effective End Date Recommendations 8
Person Image 10
Provisioning Roles to Users 10
Loading New Workers 12
Update Modes 13
Worker 14
Person Number 15
Person Name 15
Person Legislative Data 18
Work Relationship 20
Employment Terms 21
Assignment 25
Contract 27
User Information 28
Person User Manual Roles 30
Person E-mail 30
Worker Extra Information 31
Employment Terms Extra Information 32
Assignment Extra Information 33
LOADING WORKER USING HCM DATA LOADER

Worker Dat File Examples 34
Loading Supervisors 37
Employment Terms Manager 38
Assignment Manager 39
Updating Existing Workers 40
Update Modes 40
Work Relationship Changes 42
Post-Load Processes 46
Deletion Support for Worker 46
Table of Figures
Figure 1: Hire an Employee .................................................................................................................................... 15
Figure 2: Personal Details ...................................................................................................................................... 17
Figure 3: Manage Languages ................................................................................................................................. 18
Figure 4: Manage Person Name Styles .................................................................................................................. 18
Figure 5: Legislative Information ............................................................................................................................. 20
Figure 6: Work Relationship ................................................................................................................................... 21
Figure 7: Assignment.............................................................................................................................................. 24
Figure 8: Contract ................................................................................................................................................... 28
Figure 9: User and Role Provisioning Information .................................................................................................. 28
Figure 10: Person E-Mail ........................................................................................................................................ 31
Figure 11: Manager Details .................................................................................................................................... 40
2 | LOADING WORKER USING HCM DATA LOADER

Introduction
Whether implementing Oracle Fusion Global Human Resources for the first time or providing regular
updates, you can create Worker records using HCM Data Loader.
For general information about preparing data for loading using HCM Data Loader or the HCM Data
Loader file format, see the HCM Data Loader Users Guide (MOS Doc ID: 1664133.1).
How to Use the Information in This Document

This document provides a separate section for each business object that it describes. Each section
covers the following topics:
Considerations and Prerequisites What to consider before attempting to load data

Loading Describes the business object hierarchy. For each business object component, a table of
the attributes that are commonly supplied when creating new records is provided. These tables
have the following columns:
HCM Data Loader Attribute The attribute name to supply when providing your data in the
business object data (.dat) file. Attribute names with a *1 suffix are foreign-object references
that support the integration key types. As source keys are recommended where possible, the
document describes how to supply source key values. User key attributes are identified for
when you do not have the source key value.
User Interface Prompt The prompt seen on the user interface. The data that you supply in
the associated attribute derives this field value, which is not necessarily the same as the value
that you supply. For example, for the Location field on an Organization page you can supply
the Oracle Fusion surrogate ID, source key, or Oracle Fusion GUID to identify the location
uniquely. The value seen on the user interface will be the location name.
If the User Interface Prompt is prefixed with an asterisk (*), then the attribute is mandatory
when you create a new record.
Functional Description Additional information describing the attribute and how to supply
valid values.
Errors Identifies errors that may occur when loading data for the business object. Information
about resolving the error is provided.
Deletion Support Describes the extent to which the business object supports data deletion. Some
objects do not support deletion, while others may support deletion of child records only.
Translation Information on how to provide translation data for the translatable attributes in the
business object hierarchy.

Example Dat Files
This document provides working dat file examples for loading and deleting data using HCM Data
Loader. To use the source key examples, change the source system owner to a lookup code you have
preconfigured in the HRC_SOURCE_SYSTEM_OWNER lookup.
For both user key and source key examples ensure any references to foreign objects refer to data that
exists in your test environment.
Change Log
Date Version Change Reference
July 2016 1.0 Added details on external identifiers.
September 1.1 Added information about Person Image to the Considerations and Prerequisites for Worker section. In Deletion
2016 Support for Worker, included the possibility of deleting supervisor records.
October 2016 1.2 Added information to the Performing a Global Transfer section specific to a persons name.
November 1.3 Included the Working Hour Pattern component of the Worker object.
2016 Added a sample .dat file for external identifiers.
Added information about defining role mappings to the Considerations and Prerequisites for Worker section
March 2017 1.4 Added information about correcting person numbers.

Worker
The Worker business object includes all Global HR information related to a person.
You can find more details about the different components of the Worker business object in the Loading Worker
section.
You can use the Worker business object to load data through HCM Data Loader during data conversion or any other
situation where data need to be loaded in bulk.
Considerations and Prerequisites for Worker
Person
Person Number
Each person is assigned a unique person number, regardless of the person type or number of work relationships.
The enterprise option Person Number Generation Method can be set to Manual, Automatic Prior to Submission,
or Automatic Upon Final Save. To convert people with legacy person numbers and still use an automatic number
generation method, you set the person number generation method to one of the automatic options and pass the
legacy person number as part of the worker object. You must also set the Initial Person Number attribute for the
enterprise to the highest legacy person number plus one, so that the automatic person number generation continues
the legacy sequence. Alternatively, if you do not pass a person number, the application automatically assigns the
person number using the Initial Person Number value as the starting person number.
The following should be considered if you are correcting the person number once the application is in production. If
the generation method is set to Manual, then you can provide a correction to an existing person number. This
ensures consistency between the HCM Data Loader and user-interface behavior. Correction to the person number
will correct the person number for every date-effective update for the duration of the person. This is to ensure that a
person always has only one person number for unique identification and that a person is not referenced using
different person numbers over time. To correct the person number, supply the source key, the Oracle Fusion GUID,
or the Oracle Fusion surrogate ID to reference the record to be corrected. The user key alone cannot be supplied,
as the person number is the user key.
You can change the Person Number Generation Method value at any time. Changing the method must be done
with caution and coordinated with the application users because it will affect the user interface. It is recommended
not to hire people while correcting the person number if your generation method is automatic and requires switching
to Manual. If you change the method to Manual to perform a person-number correction, then it is critical to note
which of the two automatic methods was in use before the change. Once the correction is completed, the original
method must be reinstated. It may also be necessary to update the Initial Person Number value to ensure no
conflict will occur with future person numbers. If you make a correction to a person number, then run the Update
Person Search Keywords process when the correction is complete to ensure that person searches using the person
number in the Keywords field are successful. When a person number is corrected, the employment terms
assignment number, assignment assignment number, payroll relationship number, payroll assignment number, and
payroll terms number linked to this person number are also corrected automatically.

Primary Records
When creating multiple addresses, phone numbers, or e-mail addresses for one person, one of the records must be
marked as primary. This is achieved using the PrimaryFlag. To ensure that multiple occurrences are loaded
correctly, they must be processed together. To achieve this, the parent worker record should be included in the file.
If the worker already exists in Oracle Fusion, only the primary key attributes of the worker record need to be
included.
Oracle Fusion Human Capital Management Employment Model Overview
2 Tier Employment Model

The simpler version of the Fusion employment model is based on two different tiers:
Work relationship
Assignment
A person can have a work relationship with a particular legal employer for a particular period of time. Example, John
Smith has been an employee of the Vision Services legal employer since 1st January 2005.
The work relationship with the legal employer qualifies the person an employee, contingent worker, non-worker, or
pending worker and includes information about the period of service.
The term contingent worker describes a provisional worker who works for an organization on a non-permanent
basis, also known as freelancers, independent professionals, temporary contract workers, independent contractors,
or consultants.
With the term non-workers, we refer to those people who are ex-workers (for example, retirees), or who have never
been workers (for example, beneficiaries, students), but need to be considered for benefits and payment processing.
With the term pending worker, we refer to a person who will be hired or start a contingent worker placement and for
whom you create a person record that is effective before the hire or start date. When the new hire or placement is
finalized, you convert the new worker to the proposed worker type. For example, when a new employee's hire is
completed, you convert the pending worker record to an employee record. Therefore, the pending-worker functions
provide greater control of the hiring process than simply hiring an employee or adding a contingent worker with a
future start date. A person who already has a person record cannot be a pending worker.
The work relationship provides the context in which a persons assignments exist. All work relationships must
contain at least one assignment. However, a person can have multiple assignments in a single work relationship.
The assignment is a set of information, including job, position, pay, compensation, manager, working hours, and
work location that defines a workers or non-workers role for a legal employer.

A person can have any or all of employee, contingent worker and non-worker work relationships concurrently.
Example, John Smith has been an employee for the Vision Services legal employer since 1st January 2005 and a
contingent worker for the same legal employer since 1st January 2007.
A person can also have more than one active work relationship of the same type. In this case, the work relationships
must reference different legal employers. Example, John Smith has been an employee for the Vision Services legal
employer since 1st January 2005 and an employee for the Vision Canada Operations legal employer since 1st
January 2007.
3 Tier Employment Model

The 3-tier employment model is based on:
Work relationship
Employment terms (also referred to as work terms)
Assignment
Within a particular work relationship, an employee can have multiple concurrent sets of employment terms. Within
any set of employment terms, an employee can have multiple assignments, which are related to different types of
actual activities or works that need to be tracked independently.
The employments terms are conditions that have been agreed with the employee and are common across all types
of activity. Example, John Smith is an employee for the legal employer Vision Services. He has been engaged with
a G3 grade and with a salary of $25000 per annum, this is his first set of employment terms. John Smith performs
two activities that need to be tracked independently; he is an Architect in the IT Projects department and a
Consultant in the Consulting Services department, two assignments for his employment term.
The conditions captured in the employment terms can be the basis of a contract stipulated by the legal employer
and employee.
Configuration of the Employment Model

The use of the employment terms is not mandatory. Companies who do not use employment terms do not need to
configure them or see them in the user interface. The 2 tier single assignment employment model is the default out-
of-the-box configuration.

You can configure the employment model at enterprise and legal employer level. If the employment model of a legal
employer is not provided during setup, the legal employer inherits the same employment model setup as the
Enterprise.
Supported employment models:
2 Tier Multiple Assignment (2NTMA)

2 Tier Single Assignment (2NTSA)
3 Tier Single Employment Terms Multiple Assignments (3STMA)
3 Tier Single Employment Terms Single Assignment (3STSA)
3 Tier Multiple Employment Terms Multiple Assignments (3MTMA)
3 Tier Multiple Employment Terms Single Assignment (3MTSA)
2 Tier Single Contract Single Assignment (2SCSA)
The employment model is configured during the implementation phase. It is not possible to change it between 2 and
3 tiers, and vice versa, once work relationships have been created.
When you create assignments and employment terms using HCM Data Loader, you have to always take into
account that the possibility to create multiple assignments and employment terms is determined by the employment
model that is applicable for the work relationship.
In case of multiple work relationships and assignments, specifying which work relationship and assignment are
primary becomes important.
You can use the primary flag on the work relationship to mark the primary work relationship. You cannot have more
than one primary work relationship at any point in time.
Within a work relationship, an assignment is marked as primary. Each work relationship must have one and only one
primary assignment at any point in time.
Other Configuration Options for the Employment Model

Allow Employment Terms Override at Assignment Level
When creating a worker via the user interface, employment terms attributes are automatically defaulted to the
related assignment attribute values. The possibility to override these attributes on the different assignments is
configurable using the Allow Employment Terms override at Assignment level option. You can configure this
option at the Enterprise and Legal Employer level. Three choices are available:
Allow Employment Terms

Override at Assignment Description
Level
No The assignment attributes are defaulted from the employment terms and cannot
be overridden. On the employment user interfaces, they are displayed as read
only. When supplying data for loading using HCM Data Loader, the attributes are
not defaulted.
The attribute values for the employment terms must match those supplied for the
assignment.

Allow Employment Terms
Override at Assignment Description
Level
Yes The employment terms attributes are defaulted but can be overridden on the
assignment. On the employment user interfaces, they are all editable.
When supplying data for loading using HCM Data Loader, the attributes are not
defaulted.
The attribute values for the employment terms may not match those supplied for
the assignment.
Set on Employment Terms This option gives the HR Specialist the possibility to decide on a case-by-case
basis if the employment terms can be overridden at the assignment level.
Actions / Action Reasons Framework

The changes to the employment data are classified using an action and optionally an action reason. The available
actions and action reasons are visible in FSM (Manage Actions task).
The following employment objects include a mandatory Action Code attribute and optional Reason Code attribute:
Work Relationship
Employment Terms
Assignment
Assignment Grade Steps
Assignment Manager
Assignment Work Measure
Employment Terms Work Measure
Employment Terms Manager
Employment Terms Grade Steps
From a setup perspective, actions are grouped by action type.
Action Types
Action types are seeded by Oracle and have the purpose to classify the actions depending upon their business
rules. You cannot create your own action types, but you can create new actions and link them to the existing action
types.
Person Types
Person types, sometimes referred to as user person types, are subcategories of the predefined system person
types, such as employee and nonworker. Each system person type has a single person type by default, which has
the same name as the system person type. You can define additional person types for each system person type.
For example, for the system person type nonworker you could define the person types intern, retiree, volunteer, and
counselor.

Person Types can be configured in FSM (Manage Person Types).
Assignment Status Types

The predefined assignment status values indicate whether an assignment is active, inactive, or suspended and
whether the assignment is eligible for payroll processing.
You can view existing Assignment Status Types or configure new ones in FSM (Manage Assignment Status).
Any objects referenced by your worker data must exist in Oracle Fusion before loading your worker data. This is true
for referenced lookup codes also. If your worker data reference an object or value that does not exist in Oracle
Fusion your worker will fail to load.
Earliest Effective Start and Last Effective End Date Recommendations

The table below provides general guidance on how to set the earliest effective start date and the last effective end
date values for the date-effective components of the Worker business object.
This guidance does not mean that you must load data in this way. Use cases and additional validations may exist
that require you to deviate from this guidance.
Component Earliest Effective Start Date Last Effective End Date
Worker Earliest start date of the worker. The end of time.
Person Name Earliest start date of the worker. The end of time.
Person Address On or after the earliest start date of the worker. The end of time.
Person Legislative Data Earliest start date of the worker. The end of time.
Person Visa On or after the earliest start date of the worker. The end of time.
Person Contact Relationship On or after the earliest start date of the worker. As of the effective end date of the
contact relationship
Worker Extra Information On or after the earliest start date of the worker. The end of time.
Employment Terms The first employment terms must have an effective start date The end of time.
equal to the start date of the corresponding work relationship.
Subsequent employment terms can have an effective start date
equal to or after the start date of the corresponding work
relationship.
Assignment The first assignment must have an effective start date equal to The end of time.
the earliest effective start date of the corresponding employment
terms.
Subsequent assignments can have an effective start date equal
to or after the earliest effective start date of the corresponding
employment terms.
There may be further restrictions on the earliest effective start
date based on the employment model being used.
Assignment Supervisor On or after earliest effective start date of the corresponding The effective end date of the
assignment. supervisor relationship.
Assignment Work Measure On or after earliest effective start date of the corresponding The end of time.
assignment.

Component Earliest Effective Start Date Last Effective End Date
Assignment Grade Step On or after earliest effective start date of the corresponding The effective end date of the
assignment. grade step.
Assignment Extra Information On or after earliest effective start date of the corresponding The end of time.
assignment.
Contract Applicable to the specific employment model. When required, The end of time.
the earliest effective start date of the corresponding employment
terms.
Employment Terms Supervisor On or after earliest effective start date of the corresponding The effective end date of the
employment terms. supervisor relationship.
Employment Terms Work Measure On or after earliest effective start date of the corresponding The end of time.
employment terms.
Employment Terms Grade Step On or after earliest effective start date of the corresponding The effective end date of the
employment terms. grade step.
Terminating a Worker
When terminating a worker, you are required to end date only the child objects of the work relationship and
assignment. You should not provide an effective end date for the child objects of the person. For example, you
should not provide an effective end date to the person's name, since that would cause issues with the ability to
search for the worker.
Person Legislative Data

Person legislative data must start on the persons hire date. If there are multiple work relationships and each work
relationship has a different legislation, then the person legislative data must start on the person start date, not the
start date of the work relationship. When a person has a new work relationship record for a new legislation, the
application creates the person legislative record as of the original hire date with null data, and performs an update of
the person legislative record as of the date of the creation of the new work relationship with the user-provided data.
This allows for the person legislative DDF to be updated as of the new work relationship creation date and ensures
that the data is chronologically correct.
Use case:
2000 hired in UK
2005 Terminated worker
2006 Joined US military
2009 Left US military, hence becoming a US Veteran
2010 Rehired by the company in the US
In this example, a US person legislative record will be created as of 2000, the persons original start date. The US
legislative record will then be updated as of 2010, the persons US rehire date, with the person legislative DDF
details for US veteran status as provided by the user.
External Identifiers

The purpose of external identifiers is to capture an identifier used by a third-party application, such as a time device
or payroll system. The external identifier can be captured either at the person level, by supplying only the person
number, or at the assignment level, by supplying both the person number and assignment number.
The external identifier type is based on the lookup type ORA_PER_EXT_IDENTIFIER_TYPES, which can be
extended to include additional lookup codes.
The From Date and Time and To Date and Time fields include a time element. The purpose of the time element is
to ensure that the same external identifier by identifier type is not assigned to the same person or assignment for the
same date and time. This addresses the use case where a person has been assigned a time device badge identifier
in the morning but loses the badge later that same day and needs to be assigned a new badge identifier.
Person Image
A single image type of PROFILE is supported per person. The image is displayed on various HCM Cloud
application pages to help uniquely identify the persons record. If an image type is not passed, then it defaults to
PROFILE. In a future release, an image type of COVER will be supported and used on the public person page as
the background cover image for the persons public person page.
The recommended size of the image is 90 pixels by 120 pixels. Images with different pixel sizes are supported, but
the recommendation is to maintain an aspect ratio of 3 by 4 to reduce the distortion of the uploaded image. There is
no recommendation as to the resolution of the image.
The maximum size of the image file is 2 GB, but it is recommended to store images with the smallest size possible,
as required by the suggested dimensions, to improve performance handling of the image when displayed in the
application. Typically, the recommended dimensions would not need more than 2 or 3 MB, even for a high-
resolution image. The smaller the image size, the better the handling and processing of the image in the application.
Provisioning Roles to Users

You are recommended to define appropriate role mappings before you load workers using HCM Data Loader. Users
are suspended automatically when they have no roles. If you are not loading roles manually for a user, then ensure
that role provisioning rules exist so that roles can be provisioned to new users automatically. This approach will
prevent user accounts from being suspended automatically. To create role mappings, select Navigator - Setup and
Maintenance. In the Setup and Maintenance work area, perform the Manage Role Provisioning Rules task.
Worker Hierarchy
Worker data must be supplied in the Worker.dat file for processing by HCM Data Loader.
CAUTION: You must be careful when determining which key type to use when supplying Worker data. Many
components of the worker hierarchy cannot be updated if you supply only the user key.
You are recommended to supply a source key when creating workers and use it to reference the worker records you
wish to maintain.

WORKER HIERARCHY
Component Functional Description Discriminator
Worker Person working for an enterprise, for example an employee or contingent worker Worker
External Identifiers Captures a third-party payroll identifier or time-clock badge identifier for a person or ExternalIdentifier
assignment.
Person Address Address for a Worker. PersonAddress
Person Citizenship State or nation that a person identifies as being a native or naturalized member of PersonCitizenship
and is entitled to its protection. A person may have many citizenships
Person Delivery The types of communication methods for a worker, for example, IM, web address PersonDeliveryMethod
Method and so on.
Person Drivers Driving license details for a worker. PersonDriversLicense

License
Person E-Mail E-mail address of a particular type for a worker, for example an employee can have PersonEmail
home and work e-mail addresses.
Person Ethnicity Name of the cultural or racial group a worker belongs to. Ethnicity values are defined PersonEthnicity
by legislation
Person Legislative Worker data specific to a legislation, for example marital status, gender, highest PersonLegislativeData
Data education level.
Person Name Common and legislative-specific name components for a worker. For example, last PersonName
name, first name and middle names. The name may also be entered in an alternative
character set.
Person Religion Group that a person belongs to in reference to their fundamental beliefs and PersonReligion
practices. Religions are defined by legislation.
User Information A user is or was a worker authorized access to the application. It is given one or PersonUserInformation
more Enterprise Roles that grant access to various functions and data within the
application.
Person User Role to be manually granted to the user, in addition to the auto-provisioned roles. PersonUserManualRoles
Manual Roles
Person Visa Details of a workers visa or work permit, for example, number, type, status, issuing PersonVisa
authority and so on.
Work Relationship A work relationship is the highest level in the employment model and exists for every WorkRelationship
worker for a Legal Employer. This layer holds information regarding the type of
relationship that exists between the worker and the enterprise.
Employment Terms The second level in the employment model that captures the terms and conditions WorkTerms
associated with one or more assignments.
Assignment The lowest level in the employment model that identifies the details of the work to be Assignment
performed. This entity stores work terms and assigned records for employees,
contingent workers, nonworkers, and pending workers. The distinguishing attribute
for the various types of record is the Assignment Type.
Assignment Defines information about the HR budget values for an assignment. An assignment AssignmentWorkMeasure
Work Measure may be budgeted using headcount, Full Time Equivalent, points or any other user-
defined units.

Component Functional Description Discriminator
Assignment Supervisor for a particular assignment records; facilitates different relationships AssignmentSupervisor
Manager between a person and a particular supervisor. For examples, a worker can have a
line manager who manages the person overall and a project manager who controls
projects and organizes resources and people.
Assignment Identifies an increment within an assignment grade. A step rate value is associated AssignmentGradeSteps
Grade Steps with each grade step usually. Grade steps are date effective.
Working Hour Workers daily assignment hours. The start time, end time, and hours can vary WorkingHourPattern
Pattern depending on the day of the week.
Assignment The extensible flexfield data for the Assignment. AssignmentExtraInfo

Extra
Information
Contract Defines the contract associated with employment terms, for example, contract type Contract
and duration.
Employment Identifies an increment within an employment terms grade. A step rate value is WorkTermsGradeSteps
Terms Grade associated with each grade step usually. Grade Steps are date effective.
Steps
Employment Supervisor for a particular work terms record; facilitates different relationships WorkTermsSupervisor
Terms Manager between a person and a supervisor. A person can have a line manager who
manages the person overall and a project manager who controls a project and
organizes resources and people.
Employment Defines information about the HR budget values for a work terms record. Work terms WorkTermsWorkMeasure
Terms Work may be budgeted using headcount, Full Time Equivalent , points or any other user
Measure defined units
Employment The extensible flexfield data for the Employment Terms. WorkTermsExtraInfo
Terms Extra
Information
Worker Extra The extensible flexfield data for the Worker. WorkerExtraInfo
Information
Loading New Workers

It is recommended that, when loading a new worker, only the following mandatory components be supplied, with the
full date-effective history you require for each worker:
Worker
Person Name
Work Relationship
Employment Terms
Assignment
The reason for this recommendation is that you should aim at getting the workers loaded in the system.
In order to achieve that, few components are required. Once this objective has been achieved, you can focus on
additional data.

When you create a new worker, the worker Start Date and the worker Effective Start Date are equal to the start date
of the workers earliest work relationship.
When migrating data, volumes are usually extremely high. To efficiently create the workers only supply the
mandatory components so that downstream objects can also be loaded, such as salary and element entries.
Although it is not mandatory, you are recommended to supply the person legislative data with your own source key
value. If you do not supply this component, a record is auto-generated with an internal source key value.
If you are using a 3-tier employment model, or the 2 Tier Single Contract Single Assignment (2SCSA) model,
you must also supply:
Contract
Contracts cannot be loaded individually.
If you need to assign an existing user or manual user roles to your new Worker record, then also include:
User Information
Person User Manual Roles
The User Information and Person User Manual Roles record types can only be supplied for new workers and cannot
be provided separately, or updated later. If you need to update an existing user or the role associated with an
existing user, see the Loading User Update Requests Using HCM Data Loader white paper.
You can setup different behaviors for user account generation.
The Manage Enterprise HCM Information task includes the User and Role Provisioning Information section with the
Default User Name Format attribute that specifies how the user name is created.
The attribute provides different options for defaulting the user name, including Person number, Party number,
Primary work e-mail, and Defined by Oracle Identify Management.
Based on the selection chosen for your enterprise, the user name will be generated accordingly.
However, if you provide the user name in the worker service, then that user name will be used to override the
Enterprise-level setting.
Update Modes
When you load workers, you have to deal with the full date-effective history. You need to consider how HCM Data
Loader works regarding future-dated records.
HCM Data Loader supports two different update modes that impact how future dated records are handled:

Retain - Retains all existing date-effective records. This mode is recommended when you are supplying an
incremental update to an existing record.
Replace - Removes existing date-effective splits for the date range specified. This mode is useful during
data migration, when you are uploading the complete data for a record.
The mode can be controlled with a SET command:

SET PURGE_FUTURE_CHANGES <value>
Where either Y (Replace) or N (Retain) can be supplied.
It is recommended that you make use of the #NULL command for attributes that should have a null value. Leaving
attribute values unspecified will ensure existing attribute values are retained. For more information and examples of
this behavior, see the HCM Data Loader Users Guide.
Worker
The worker record holds details such as the person number, date of birth, country of birth, blood type, and
correspondence language.
Whether creating a new worker or updating an existing worker, you should pass only one row for the worker
component. No date-effective attributes are exposed on the worker component. If any attribute needs to be
corrected on the worker object after the creation, then a correction must be performed.
The discriminator Worker is used to load worker records using HCM Data Loader. The following Worker attributes
are commonly used when loading a new Worker. Other optional attributes may be available.
To identify the attribute names for deployed flexfield segments, generate the Worker template file.
WORKER ATTRIBUTES
HCM Data Loader

User interface prompt Functional Description
Attribute
SourceSystemId/ Person Number You must provide a unique reference for the record being created. Supply either a
SourceSystemOwner source key or the user key attribute PersonNumber.
EffectiveStartDate * Hire Date The hire date for the worker. Date-tracked updates are not supported. To correct
existing attribute values supply the workers hire date.
EffectiveEndDate If left blank this will default to the end of time.

Note: Workers are not end-dated, so if supplying the latest date-effective change,
leave this attribute blank.
PersonNumber Person Number If you have configured for person numbers to be automatically generated then you
must supply a source key to uniquely reference this record. This same reference
must then be supplied for all child components using the
PersonId(SourceSystemId) attribute and hint.
StartDate * Hire Date The hire date for the worker.
ActionCode * Hire Action The action performed, for example HIRE.
ReasonCode * Hire Reason Optional, the reason for the action.
DateOfBirth Date of Birth The date of birth.

HCM Data Loader
Attribute
ApplicantNumber Unique number for people who are applicants. This is in addition to
PersonNumber, allowing global tracking of applicants.
BloodType The blood type of the worker. This attribute is validated using the lookup
BLOOD_TYPE.
FLEX:PER_PERSON Only supply if loading Persons Attributes DFF data. The context for the DFF
S_DFF data is supplied against this attribute.
The value supplied will derive the value seen in the field specified in the User Interface Prompt.
*1 The foreign object references support use of all four key types: Oracle Fusion surrogate ID, Oracle Fusion GUID, source key, and
user key.
Figure 1: Hire an Employee

Navigation: New Person - Hire an Employee
Person Number
The person number is an identifier that uniquely identifies a person, regardless of their relationship with the
enterprise, within the Oracle Fusion application. It does not provide any specific information about the person type,
since a person may have several different types of relationships with the enterprise at the same time. For example,
a person could be both an Employee and a Contact of another employee at the same time.
Person Name
The person name record holds the common and legislative specific components of the workers name.
Person names will always be created with both a global name and local name. Based on the name type passed, the
other name will be automatically derived. If there is a need for a persons name to be in 2 different character sets,

the local name can be populated with the locally specific name. The typical use case is that only the Global Name is
required and the application will copy the Global Name to the Local Name automatically.
When a core name field is not available for a legislation, for example, Last Name Kanji for the Japanese legislation,
the data is stored in one of the Name Information 1 attribute. The person name styles table stores the mapping of
the name style to the name attributes. The name style is the same for both the global and local name records.
If there is a requirement to define a specific name attribute for a specific legislation, the manage person name styles
feature allows the use of attributes Name Information 15 through Name Information 30 for these requirements. For
example, if you want to define a name attribute for Doing Business As in the United States, you can use the Name
Information 15 attribute. Name Information 1 through Name Information 14 are reserved for use by Oracle
Development. There is no need to define flexfields for this requirement.
The discriminator PersonName is used to load Person Name records using HCM Data Loader. The following
PersonName attributes are commonly used when loading a new worker. Other optional attributes may be available.
PERSON NAME ATTRIBUTES
HCM Data Loader

Attribute
SourceSystemId/ * Person Number You must provide a unique reference for the record being created. Due to a
SourceSystemOwner * Name Type problem with the user key defined for this record, you must supply a source key if
you are supplying date-effective history for person name. If no date-effective history
is being supplied, you can supply the user key attributes PersonNumber,
EffectiveStartDate, and NameType.
PersonId* * Person Number Unique reference to the person this name is for. If using user keys supply the
PersonNumber attribute.
If you supplied a source key for the Worker record, supply the same
SourceSystemId value here and add the source key hint to this attribute name, for
example: PersonId(SourceSystemId).
EffectiveStartDate * Effective Start Date The start date of the person name or the update to the person name if supplying
date-effective history. For the first date-effective record, this must match the
EffectiveStartDate supplied for the Worker record.
EffectiveEndDate Effective End Date If you are supplying date-effective history the last day of the date-effective changes.
If left blank, this record will continue until the end of time.
LegislationCode Not displayed The legislation of the legal employer into which the worker is being hired. The
legislation code determines the name style that is presented in the user interface.
Legislation code is mandatory during the worker creation. The legislation code is
always the same on both the global and local name records.
NameType Not displayed The type of name. The valid values are GLOBAL for the global name record and
the legislation code of the name object for the local name record.
CharSetContext Global-Name Language, The global and local name language. The global record derives the value from the
Local-Name Language HCM enterprise setting of the Global Person Name Language. You can leave this
null for the global record and let the application default the correct value. If you are
creating a local name record, this field is required. You can find the language code
valid values from the Manage Languages task in Setup and Maintenance.
LastName * Last Name The persons last name.
FirstName First Name The persons first name.
MiddleNames Middle Name The persons middle names.

Title Title The persons title, the means of addressing the person. This attribute value is
validated using the TITLE lookup.
PreviousLastName The persons previous last name.
User Key attributes that are required only if no other key type is supplied to uniquely identify the object they reference
PersonNumber Person Number Used to uniquely identify the parent worker record if using user keys. Supply the
person number specified for the Worker record.
This is not required if you supplied a source key to reference the parent Worker
record.
user key.
Figure 2: Personal Details

Navigation: New Person - Hire an Employee - Person Information

Figure 3: Manage Languages
Navigation: Setup and Maintenance Manage Languages
Figure 4: Manage Person Name Styles

Navigation: Setup and Maintenance Manage Person Name Styles

The legislative data record holds information such as the persons gender and marital status.

The discriminator PersonLegislativeData is used to load person legislative data records using HCM Data Loader.
The following PersonLegislativeData attributes are commonly used when loading a new worker. Other optional
attributes may be available.
PERSON LEGISLATIVE DATA ATTRIBUTES
HCM Data Loader

Attribute
SourceSystemId/ * Person Number You must provide a unique reference for the record being created. Due to a
SourceSystemOwner problem with the user key defined for this record, you must supply a source key
if you are supplying date-effective history for the legislative data. If no date-
effective history is being supplied, you can supply the user key attributes
PersonNumber, EffectiveStartDate, and LegislationCode.
PersonId* * Person Number Unique reference to the person this legislative data is for. If using user keys
supply the PersonNumber attribute.
SourceSystemId value here and add the source key hint to this attribute name
for example, PersonId(SourceSystemId).
EffectiveStartDate * Effective Start Date The start date of the legislative data or the update to the legislative data if
supplying date-effective history. For the first date-effective record, this must
match the EffectiveStartDate supplied for the Worker record.
EffectiveEndDate Effective End Date If supplying date-effective history the last day of the date-effective changes. If
left blank, this record will continue until the end of time.
LegislationCode The legislation code, derived from the legal entity.
MaritalStatus Marital Status The marital status of the worker. This attribute is validated using the
MAR_STATUS lookup.
Sex Gender Gender. This attribute is validated using the SEX lookup.
HighestEducationLevel Highest Education Level Legislation specific value that indicates the highest level of education for the
person. This attribute is validated using the
PER_HIGHEST_EDUCATION_LEVEL lookup.
FLEX:PER_PERSON_L Only supply if loading Person Legislative Attributes DFF data. The context for
EGISLATIVE_DFF the DFF data is supplied against this attribute.
FLEX:PER_PERSON_L Only supply if loading Person Legislative Information DFF data. The context
EGISLATIVE_DATA_L for the DFF data is supplied against this attribute.
EG_DDF
PersonNumber * Person Number Used to uniquely identify the parent worker if using user keys. The person
number specified for the Worker record.
record.
user key.

Figure 5: Legislative Information
Navigation: New Person - Hire an Employee - Person Information
Work Relationship
A work relationship is the highest level in the employment model and exists for every worker for a Legal Employer.
This layer holds information regarding the type of relationship that exists between the person and the enterprise.
The discriminator WorkRelationship is used to load worker records using HCM Data Loader. The following
WorkRelationship attributes are commonly used when loading a new worker. Other optional attributes may be
available.
WORK RELATIONSHIP ATTRIBUTES
HCM Data Loader User interface

Functional Description
Attribute prompt
SourceSystemId/ * Person Number You must provide a unique reference for the record being created. Supply
SourceSystemOwner * Legal Employer either supply a source key or the user key attributes
LegalEmployerName, PersonNumber, DateStart, and WorkerType.
* Start Date
LegalEmployerName * Legal Employer The name of the legal entity.
PersonId * * Person Number Unique reference to the person this work relationship is for. If using user keys
supply the PersonNumber attribute.
SourceSystemId value here and add the source key hint to this attribute name,
that is, PersonId(SourceSystemId).
DateStart * Start Date The start date of the period of employment.
WorkerType Specifies whether this period of service is for an employee, contingent worker,
pending worker, or nonworker.
It is validated using the PER_PERSON_TYPE lookup.
Valid values are:
E Employee
C Contingent worker
P Pending worker
N Nonworker
LegalEntityId*1 The legal entity for this period of service. If using user keys supply a value for
the Organization attribute.
This attribute also supports the integration key type values. If you supplied a
source key when creating the legal entity you can supply the same value here

Attribute prompt
by appending the source key hint to the attribute name, for example,
LegalEntityId(SourceSystemId).
ActionCode The action performed for this period of service record. For example, Hire, Add
Pending Worker, Manager Change, and so on.
PrimaryFlag Specify Y if this is the primary employment period for the legal entity.
LegalEmployerSeniorityDate Legal Employer Seniority Original date of hire.

Date
EnterpriseSeniorityDate Enterprise Seniority Date Adjusted Service Date. For example, for a rehire that was part of an
acquisition, all plans may use the original hire date if the worker was rehired
within 90 days of termination, except a 401k plan, which may use the adjusted
service date that was originally populated upon acquisition.
FLEX:PER_PPS_DF Supply only if loading Work Relationship Attributes descriptive flexfield data.
The context of the descriptive flexfield data is supplied against this attribute.
FLEX:PER_PPS_LEG_DDF Supply only if loading Work Relationship Legislative Information descriptive

flexfield data. The context of the descriptive flexfield data is supplied against
this attribute.
PersonNumber * Person Number Used to uniquely identify the parent work relationship if using user keys. The
This is not required if you supplied a source key to reference the parent
Worker record.
user key.
Figure 6: Work Relationship

Navigation: New Person - Hire an Employee - Employment Information
Employment Terms
The employment terms captures the terms and conditions associated with one or more assignments.
The discriminator WorkTerms is used to load Employment Term records using HCM Data Loader. The following
WorkTerms attributes are commonly used when loading a new worker. Other optional attributes may be available.

EMPLOYMENT TERMS ATTRIBUTES
HCM Data Loader

Attribute
SourceSystemId/ * Assignment Number You must provide a unique reference for the record being created. Supply either a
SourceSystemOwner source key or the user key attribute AssignmentNumber.
AssignmentNumber * Assignment Number Uniquely identifies the employment terms.

*1
PeriodOfServiceId * Person Number Unique reference to the parent work relationship. If using user keys supply values
* Legal Employer Name for these attributes: LegalEmployerName, PersonNumber, DateStart, and
WorkerType.
* Start Date
If using source keys supply the value SourceSystemId value from the
* Worker Type WorkRelationship record and add the source key hint to this attribute name, that
is, PeriodOfServiceId(SourceSystemId)
EffectiveStartDate Effective Start Date The start date of the employment terms record or the update to the employment
terms if you are supplying date-effective history.
EffectiveEndDate Effective End Date If you are supplying date-effective history, the last date of the date-effective
changes. If supplying multiple changes per day (MCPD) and this is not the last
change for the EffectiveStartDate the EffectveEndDate must have the same value
as the EffectiveStartDate. If left blank, the employment terms will continue until
the end time.
EffectiveSequence Employment terms support multiple changes per day (MCPD). If this is the first
change for the EffectiveStartDate supply a value of 1. Later changes on the same
EffectiveStartDate must have a unique and sequential EffectiveSequence. If left
blank the next available sequence for the EffectiveStartDate will be assigned, but
this attribute cannot be left blank if supplying date-effective history for a new
worker.
EffectiveLatestChange A value of Y tells Oracle Fusion that this record is the last change for the
EffectiveStartDate for a worker. All changes for the same worker, for the same
EffectiveStartDate that are not the last change on that date must have a value of
N.
ActionCode * Action The action performed for this employment terms record. For example, Hire, Add
Pending Worker, Manager Change, and so on.
PersonTypeId*1 The unique reference to the person type. Person type examples are Assignee,
Consultant, Expatriate, Agency/Temp, Apprentice, Contractor, and Trainee.
If using user keys supply the PersonType attribute.
This attribute also supports the integration key type values by appending the
appropriate hint to the attribute name.
PositionId*1 Position The unique reference to the workers position. If using user keys supply the
PositionCode attribute.
JobId*1 Job The unique reference to the workers job. If using user keys supply the JobCode,
BusinessUnitShortCode attributes.
OrganizationId*1 The unique reference to the workers department. If using user keys supply the
DepartmentName attribute.
ReportingEstablishment Reporting Establishment The workers reporting establishment.

HCM Data Loader
Attribute
LocationId* Location The unique reference to workers location. If using user keys supply the
LocationCode, BusinessUnitShortCode attributes.
WorkerCategory Worker Category The worker category. This attribute is validated using the EMPLOYEE_CATG
lookup.
AssignmentCategory Assignment Category The assignment category. This attribute is validated using the EMP_CAT lookup.
PermanentTemporary Regular or Temporary Is the worker regularly or temporary?
FullPartTime Full Time or Part Time Is the worker full or part time?
NormalHours Standard Work Hours The normal working hours.
StartTime Start Time The work day normal start time.
EndTime End Time The work day normal end time.
PeopleGroup People Group If your people group key flex is configured with multiple segments, provide the
concatenated value in this attribute, separating the values with the separator you
configured for the People Group Keyflex. Example, where the separator is a full
stop '.:
METADATA|WorkTerms|PeopleGroup|
MERGE|WorkTerms|A..C|
If your People Group Keyflex uses the pipe '|' character, you will need to prefix
this with the escape character (\) to ensure that the pipe character is not
interpreted as a new attribute value.
Example:
METADATA|WorkTerms|PeopleGroup|...
MERGE|WorkTerms|W\|\|C|...
FLEX:PER_ASG_DF Only supply if loading Assignment Attributes DFF data. The context for the
DFF data is supplied against this attribute.
FLEX:PER_ASG_LEG_ Only supply if loading Legislative Assignment Attributes DFF data. The
DDF context for the DFF data is supplied against this attribute.
person number specified on the work relationship.
WorkRelationship record
LegalEmployerName * Legal Employer Name Used to uniquely identify the parent work relationship if using user keys. The legal
employer name for the work relationship.
DateStart * Start Date Used to uniquely identify the parent work relationship if using user keys. The date
start specified on the work relationship.

HCM Data Loader
Attribute
WorkerType * Worker Type Used to uniquely identify the parent work relationship if using user keys. The
worker type specified on the work relationship.
PersonType The user-defined person type.
PositionCode Position The code for the workers position.
BusinessUnitShortCode The short code for the business unit the job and location belong to. Only required
if supplying the JobCode or LocationCode.
JobCode Job The code for the workers job.
DepartmentName Department The name of the workers department.
LocationCode Location The code of the workers location.
user key.
Figure 7: Assignment

Assignment
For the 3 Tier employment model, the assignment attribute values can differ from the employment terms. However,
for the 2 Tier employment model you must supply the assignment record with identical date-effective splits and
attribute values to the Employment Terms record.
The discriminator Assignment is used to load Assignment records using HCM Data Loader. The following
Assignment attributes are commonly used when loading a new worker. Other optional attributes may be available.
ASSIGNMENT ATTRIBUTES

Attribute prompt
SourceSystemId/ * Assignment Number You must provide a unique reference for the record being created. Supply
SourceSystemOwner either a source key or the user key attribute AssignmentNumber.
AssignmentNumber Assignment Number Uniquely identifies the assignment.
WorkTermsAssignmentId* Unique reference to the parent employment terms. If using user keys supply
values for these attributes: WorkTermsNumber.
WorkTerms record and add the source key hint to this attribute name, that is,
WorkTermsAssignmentId(SourceSystemId).
EffectiveStartDate * Effective Start Date The start date of the assignment record or update to the assignment if you are
supplying date-effective history.
changes. If supplying multiple changes per day (MCPD) and this is not the last
change for the EffectiveStartDate the EffectveEndDate must have the same
value as the EffectiveStartDate. If left blank the employment terms will
continue until the end time.
EffectiveSequence Assignment supports multiple changes per day (MCPD). If this is the first
change for the EffectiveStartDate, supply a value of 1. Later changes on the
same EffectiveStartDate must have a unique and sequential
EffectiveSequence. If left blank, the next available sequence for the
EffectiveStartDate will be assigned, but this attribute cannot be left blank if
supplying date-effective history for a new worker.
EffectiveLatestChange A value of Y tells Oracle Fusion that this record is the last change for the
EffectiveStartDate for a worker. All changes for the same worker, for the same
EffectiveStartDate that are not the last change on that date must have a value
of N.
PeriodOfServiceId Unique reference to the parent work relationship. If using user keys supply
values for these attributes: LegalEmployerName, PersonNumber, DateStart,
and WorkerType.
ActionCode Action The action performed for this assignment record. For example, Hire, Add
Pending Worker, Manager Change and so on.
PersonTypeId*1 The unique reference to the person type. Person type examples are Assignee,
Consultant, Expatriate, Agency/Temp, Apprentice, Contractor, Trainee and so
on. If using user keys supply the PersonType attribute.

Attribute prompt
PositionId*1 Position The unique reference to the workers position. If using user keys supply the
PositionCode attribute.
*1
JobId Job The unique reference to the workers job. If using user keys supply the
JobCode, BusinessUnitShortCode attributes.
OrganizationId*1 Deparment The unique reference to the workers department. If using user keys supply the
DepartmentName attribute.
ReportingEstablishment Reporting Establishment The workers reporting establishment
LocationId*1 Location The unique reference to workers location. If using user keys supply the
LocationCode, BusinessUnitShortCode attributes.
WorkerCategory Worker Category The worker category. This attribute is validated using the EMPLOYEE_CATG
lookup.
AssignmentCategory Assignment Category The assignment category. This attribute is validated using the EMP_CAT
lookup.
PermanentTemporary Regular or Temporary Is the worker regularly or temporary?
FullPartTime Full Time or Part Time Is the worker full or part time?
NormalHours Standard Work Hours The normal working hours.
StartTime Start Time The work day normal start time.
EndTime End Time The work day normal end time.
PeopleGroup People Group If your people group key flex is configured with multiple segments, provide the
concatenated value in this attribute, separating the values with the separator
you configured for the People Group Keyflex. Example, where the separator is
a full stop '.:
METADATA|WorkTerms|PeopleGroup|
MERGE|WorkTerms|A..C|
If your People Group Keyflex uses the pipe '|' character, you will need to prefix
this with the escape character (\) to ensure that the pipe character is not
interpreted as a new attribute value.
Example:
METADATA|WorkTerms|PeopleGroup|...
MERGE|WorkTerms|W\|\|C|...
FLEX:PER_ASG_DF Only supply if loading Assignment Attributes DFF data. The context for the
DFF data is supplied against this attribute.
FLEX:PER_ASG_LEG_DDF Only supply if loading Legislative Assignment Attributes DFF data. The
context for the DFF data is supplied against this attribute.

Attribute prompt
WorkTermsNumber Used to uniquely identify the parent employment terms if using user keys. The
work terms number for the employment terms.
WorkTerms record
PersonType The user-defined person type.
PositionCode Position The code for the workers position.
JobCode Job The code for the workers job.
BusinessUnitShortCode The short code for the business unit the job and Location belong to. Only
required if supplying the JobCode or LocationCode.
DepartmentName Deparment The name of the workers department.
LocationCode Location The code of the workers location.
user key.
Contract
The discriminator Contract is used to load Contract records using HCM Data Loader. The following Contract
attributes are commonly used when loading a new worker if you are using a 3-tier employment model, or the 2 Tier
Single Contract Single Assignment (2SCSA) model. Other optional attributes may be available.
CONTRACT ATTRIBUTES
HCM Data Loader

Attribute
SourceSystemId/ * Assignment Number You must provide a unique reference for the record being created. Supply either a
SourceSystemOwner source key or the user key attribute AssignmentNumber.
AssignmentId* Unique reference to the parent assignment. If using user keys supply values for
these attributes: AssignmentNumber.
If using source keys supply the value SourceSystemId value from the Assignment
record and add the source key hint to this attribute name, that is,
AssignmentId(SourceSystemId).
EffectiveStartDate * Effective Start Date The start date of the contract record or the update to the contract if you are
supplying date-effective history.
changes. If left blank the employment terms will continue until the end time.
ContractType The type of contract. This attribute is validated using the CONTRACT_TYPE
lookup.
Duration The duration of the contract.
DurationUnits The units of time in which the duration is expressed. This attribute is validated using
the QUALIFYING_UNITS lookup.
FLEX:PER_CONTRAC Only supply if loading Contract Attributes DFF data. The context for the DFF data
T_DF is supplied against this attribute.

HCM Data Loader
Attribute
FLEX:PER_CONTRAC Only supply if loading Contract Legislative Informations DFF data. The context
T_LEG_DDF for the DFF data is supplied against this attribute.
AssignmentNumber * Assignment Number Used to uniquely identify the parent assignment if using user keys. The assignment
number for the assignment.
This is not required if you supplied a source key to reference the parent Assignment
record.
user key.
Figure 8: Contract
User Information
The discriminator PersonUserInformation is used to create user request records using HCM Data Loader.
When dealing with users it is important to consider that:
It is not possible to create a user without a worker.
The Worker business object does not create users directly. It generates the user provisioning requests.
PersonUserInformation is not mandatory. The user is created even when the component is not entered.
However, you may want to include this component to provide additional options related to the creation of
the user.
User generation is controlled by the User and Role Provisioning Information options on the Manage Enterprise
HCM Information task.
Figure 9: User and Role Provisioning Information

Navigation: Workforce Structure Manage Enterprise HCM Information

The following PersonUserInformation attributes are commonly used when loading a new worker when you want to
associate a person with an existing user, or specify the username for a new user. Other optional attributes may be
available.
This component does not accept source keys. You must provide user key values to reference the parent Worker
record.
Use Cases:
1. Create the worker without creating any users.
2. Create the worker and link it to an existing user.
a. Providing the user name
b. Providing the e-mail address
3. Send the credentials to a different e-mail address instead of the default e-mail addresses.
4. Avoid sending any e-mail notification with the credentials.
5. Create the user account with start date after the hire date.
PERSON USER ATTRIBUTES

Attribute prompt
PersonNumber * not displayed The person number supplied for the parent worker record.
UserName Optional user name to use if creating a user record, or if using Username
matching. See the UsernameMatchingFlag attribute.
StartDate The start date of the user account. If it is not provided, the hire date is used.
UserGUID If provided a new user account will not be created. Instead, the worker will be
associated with the existing user identified by the users GUID. The GUID is
available from LDAP.
SendCredentialsEmailFlag "Y" or "N". Indicates whether a user name and password notification (for example,
email) should be sent. If not set, defaults to "Y".
CredentialsEmailAddress If this attribute is supplied (not null), the credentials are sent to this email address
instead of the default email addresses.
GeneratedUserAccountFlag "Y" or "N". Indicates whether a user account should be created. If not set, defaults
to "Y".
UsernameMatchingFlag True or false.

If username matching is set to true then an attempt will be made to find a user
with a username that matches the value of the UserName attribute. If a user is
found then the worker is associated with the existing user and a new user is not
created. If this attribute is not set, it defaults to False.
EmailMatchingFlag Indicates whether the system should attempt to look for an existing user with the
value supplied in the EmailAddress attribute. If a user is found with this e-mail
address, it will be associated with the worker and a new user account is not be
created.
If the UserGuid attribute is provided then e-mail matching will not be performed,
as matching on the UserGuid takes precedence.
EmailAddress The e-mail address to use for e-mail matching. See EmailMatchingFlag

Attribute prompt
CreateUserIfNoMatchingEmail Indicates whether a new user should be created if the e-mail address of the
Flag worker does not match the e-mail address of any existing user. Only used when
EmailMatchingFlag is set true.
Person User Manual Roles

The discriminator PersonUserManualRoles is used to load Person User Manual Roles records using HCM Data
Loader. The following PersonUserManualRoles attributes are commonly used when loading a new worker. Other
optional attributes may be available.
This component does not accept source keys; you must provide user key values to reference the parent Worker
record.
PERSON USER MANUAL ROLES ATTRIBUTES
HCM Data Loader

Attribute
PersonNumber * not displayed The person number supplied for the parent UserInformation record.
UserName * not displayed The username supplied for the parent UserInformation record.
RoleName * not displayed The name of the role, as displayed in the Oracle Fusion interface. This attribute is
case-sensitive and you should provide an exact match.
Person E-mail
The discriminator PersonEmail is used to load Person E-mail records using HCM Data Loader. The following
PersonEmail attributes are commonly used when loading a new worker. Other optional attributes may be available.
It is advised that you only supply the Person E-mail record when creating a new worker if the user account name to
be generated uses the E-mail address.
PERSON E-MAIL ATTRIBUTES
HCM Data Loader

Attribute
SourceSystemId/ * Person Number You must provide a unique reference for the record being created. Supply either a
SourceSystemOwner * Type source key or the user key attributes PersonNumber, EmailType, and
EmailAddress.
* Address
PersonId*1 * Person Number Unique reference to the person this name is for. If using user keys supply the
SourceSystemId value here and add the source key hint to this attribute name that
is, PersonId(SourceSystemId).
EmailType * Type The type of e-mail, for example, work, personal. This attribute is validated using
the EMAIL_TYPE lookup.

HCM Data Loader
Attribute
EmailAddress * Address The e-mail address.
DateFrom The date the e-mail address is valid from.
PrimaryFlag * Primary Y if this is the primary e-mail address for the worker, otherwise N.
record.
user key.
Figure 10: Person E-Mail

Navigation: New Person - Hire an Employee: Person Information
Worker Extra Information

The discriminator WorkerExtraInfo is used to load Worker Extra Information records using HCM Data Loader. The
following WorkerExtraInfo attributes are commonly used when loading a new worker. Other optional attributes may
be available.
You cannot load Worker Extra Information records independently; they must always be supplied with the parent
Worker record, in the same Worker.dat file.
WORKER EXTRA INFORMATION COMPONENT
HCM Data Loader User Interface

Attribute Prompt
SourceSystemId / * Person Number You must provide a unique reference for the record being created. Due to a
SourceSystemOwner problem with the user key defined for this record, you must supply a source key if
you are supplying date-effective history for the extra information data. If no date-
effective history is being supplied you can alternatively supply the user key
attributes; PersonNumber, PeiInformationCategory, EffectiveStartDate
PersonId*1 * Person Number Unique reference to the person this EFF data is for. If using user keys supply the

HCM Data Loader User Interface
Attribute Prompt
SourceSystemId value here and add the source key hint to this attribute name that
is, PersonId(SourceSystemId)
PeiInformationCategory Supply the EFF context code
EffectiveStartDate * Effective Start Date The start date of the Person EIT Information data or the update to the Person
EIT information if supplying date-effective history.
EffectiveEndDate If supplying date-effective history the end date of the date-effective changes, If left
blank this record will continue until the end of time.
FLEX:PER_PERSON_ The context code for the EFF data is supplied against this attribute.
EIT_EFF
EFF_CATEGORY_CO The category code for the EFF data is supplied against this attribute.
DE
record.
user key.
Employment Terms Extra Information

The discriminator WorkTermsExtraInfo is used to load Employment Terms Extra Information records using HCM
Data Loader. The following WorkTermsExtraInfo attributes are commonly used when loading a new worker. Other
You cannot load Employment Terms Extra Information records independently; they must always be supplied with
the parent Employment Terms record, in the same Worker.dat file.
EMPLOYMENT TERMS EXTRA INFORMATION ATTRIBUTES
HCM Data Loader

Attribute
SourceSystemId / * Assignment Number You must provide a unique reference for the record being created. Due to a
SourceSystemOwner problem with the user key defined for this record, you must supply a source key
if you are supplying date-effective history. If no date-effective history is being
supplied, you can supply the user key attributes AssignmentNumber,
AeiInformationCategory, and EffectiveStartDate.

HCM Data Loader
Attribute
AssignmentId*1 * Assignment Number Unique reference to the parent employment terms. If using user keys supply
values for these attributes: AssignmentNumber
WorkTerms record and add the source key hint to this attribute name, that is,
AssignmentId(SourceSystemId)
EffectiveStartDate Effective Start Date The start date of the Assignment EIT Information EFF record, or the update to
the Assignment EIT Information if supplying date-effective history.
EffectiveEndDate Effective End Date If supplying date-effective history the end date of the date-effective changes. If
left blank the EFF data will continue until the end time.
AeiInformationCategory Supply the EFF context code
InformationType Supply the EFF context code
LegislationCode The legislation code for the legal entity.
FLEX:PER_ASSIGNME The context code for the Assignment EIT Information EFF data is supplied
NT_EIT_EFF against this attribute.
DE
AssignmentNumber * Assignment Number Used to uniquely identify the parent employment terms if using user keys. The
assignment number for the employment terms.
employment terms record.
user key.
Assignment Extra Information

The discriminator AssignmentExtraInfo is used to load Assignment Extra Information records using HCM Data
Loader. The following AssignmentExtraInfo attributes are commonly used when loading a new worker. Other
You cannot load Assignment Extra Information records independently; they must always be supplied with the parent
Assignment record, in the same Worker.dat file.
ASSIGNMENT EXTRA INFORMATION ATTRIBUTES
HCM Data Loader

Attribute
SourceSystemId / * Assignment Number You must provide a unique reference for the record being created. Due to a
SourceSystemOwner problem with the user key defined for this record, you must supply a source key,
if you are supplying date-effective history. If no date-effective history is being
supplied you can alternatively supply the user key attributes;
AssignmentNumber, AeiInformationCategory, EffectiveStartDate

HCM Data Loader
Attribute
AssignmentId*1 * Assignment Number Unique reference to the parent assignment. If using user keys supply values for
these attributes: AssignmentNumber
assignment record and add the source key hint to this attribute name, that is,
EffectiveStartDate Effective Start Date The start date of the Assignment EIT Information EFF record, or the update
the Assignment EIT Information EFF if supplying date-effective history.
EffectiveEndDate Effective End Date If supplying date-effective history the end date of the date-effective changes. If
left blank the EFF data will continue until the end time.
AeiInformationCategory Supply the EFF context code
InformationType Supply the EFF context code
LegislationCode The legislation code for the legal entity.
FLEX:PER_ASSIGNME The context code for the Assignment EIT Information EFF data is supplied
NT_EIT_EFF against this attribute.
DE
AssignmentNumber * Assignment Number Used to uniquely identify the parent assignment if using user keys. The
assignment record.
user key.
Worker Dat File Examples
Creating new Workers

This file creates new workers with the core mandatory components that we recommend you supply. Source keys
are used so that the data can be more easily referenced for update later.
Worker.dat
METADATA|Worker|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate|
PersonNumber|StartDate|DateOfBirth|ActionCode
MERGE|Worker|VISION|1008|1976/09/08|4712/12/31|1008|1976/09/08|1952/05/21|HIRE
MERGE|Worker|VISION|1009|1982/02/08|4712/12/31|1009|1982/02/08|1966/04/21|HIRE
METADATA|PersonLegislativeData|SourceSystemOwner|SourceSystemId|EffectiveStartDate|Ef
fectiveEndDate|PersonId(SourceSystemId)|LegislationCode|Sex|MaritalStatus
MERGE|PersonLegislativeData|VISION|1008_LEGISLATIVE|1976/09/08|4712/12/31|1008|US|M|M
MERGE|PersonLegislativeData|VISION|1009_LEGISLATIVE|1982/02/08|4712/12/31|1009|US|F|D
METADATA|PersonName|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndD
ate|PersonId(SourceSystemId)|NameType|LegislationCode|Title|LastName|FirstName
MERGE|PersonName|VISION|1008_GLOBAL|1976/09/08|4712/12/31|1008|GLOBAL|US|MR.|Smythe|B
ob

MERGE|PersonName|VISION|1009_GLOBAL|1982/02/08|4712/12/31|1009|GLOBAL|US|MISS|Grey|Su
san
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|L
egalEmployerName|DateStart|WorkerType|PrimaryFlag
MERGE|WorkRelationship|VISION|1008_POS|1008|Cox-6-CWB|1976/09/08|E|Y
MERGE|WorkRelationship|VISION|1009_POS|1009|Cox-6-CWB|1982/02/08|E|Y
METADATA|WorkTerms|SourceSystemOwner|SourceSystemId|PeriodOfServiceId(SourceSystemId)
|ActionCode|EffectiveStartDate|EffectiveEndDate|EffectiveSequence|EffectiveLatestChan
ge|AssignmentName|AssignmentNumber|PrimaryWorkTermsFlag
MERGE|WorkTerms|VISION|1008_EMP_TERM|1008_POS|HIRE|1976/09/08|4712/12/31|1|Y|ET1008|1
008_WT|Y
MERGE|WorkTerms|VISION|1009_EMP_TERM|1009_POS|HIRE|1982/02/08|2010/01/04|1|Y|ET1009|1
009_WT|Y
MERGE|WorkTerms|VISION|1009_EMP_TERM|1009_POS|JOB_CHANGE|2010/01/05|4712/12/31|1|Y|ET
1009|1009_WT|Y
METADATA|Assignment|SourceSystemOwner|SourceSystemId|ActionCode|EffectiveStartDate|Ef
fectiveEndDate|EffectiveSequence|EffectiveLatestChange|WorkTermsAssignmentId(SourceSy
stemId)|AssignmentName|AssignmentNumber|AssignmentStatusTypeCode|PersonTypeCode|Busin
essUnitShortCode|LocationId(SourceSystemId)|OrganizationId(SourceSystemId)|JobId(Sour
ceSystemId)|PrimaryAssignmentFlag
MERGE|Assignment|VISION|1008_EMP_ASG|HIRE|1976/09/08|4712/12/31|1|Y|1008_EMP_TERM|100
8|1008|ACTIVE_PROCESS|Employee|FUSIONHCMQA|LOC_HQ|SALES_HW|SALES_CONS|Y
MERGE|Assignment|VISION|1009_EMP_ASG|HIRE|1982/02/08|2010/01/04|1|Y|1009_EMP_TERM|100
9|1009|ACTIVE_PROCESS|Employee|FUSIONHCMQA|LOC_HQ|SALES_HW|SALES_MGR|Y
MERGE|Assignment|VISION|1009_EMP_ASG|JOB_CHANGE|2010/01/05|4712/12/31|1|Y|1009_EMP_TE
RM|1009|1009|ACTIVE_PROCESS|Employee|FUSIONHCMQA|LOC_RD_UK|SALES_HW|SALES_CONS|Y
Supplying non-mandatory data for new Workers

This file creates the non-mandatory person data for new workers. Source keys are used so that the data can be
more easily referenced for update later.
The Worker record is included to allow the child records to be grouped and processed together. This avoids
potential locking issues when updating the worker.
Worker.dat
METADATA|Worker|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate
MERGE|Worker|VISION|1008|1976/09/08|4712/12/31
MERGE|Worker|VISION|1009|1982/02/08|4712/12/31
METADATA|PersonAddress|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveE
ndDate|PersonId(SourceSystemId)|AddressType|Country|AddressLine1|TownOrCity|Region1|R
egion2|PostalCode
MERGE|PersonAddress|VISION|1008_HOME|1976/09/08|4712/12/31|1008|HOME|US|211 Upwest
North 6th Street|New York|New York|NY|10130
MERGE|PersonAddress|VISION|1009_HOME|1982/02/08|4712/12/31|1009|HOME|US|Avenue Beach
Heights|New York|New York|NY|10130
METADATA|PersonCitizenship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|
DateFrom|DateTo|LegislationCode|CitizenshipStatus
MERGE|PersonCitizenship|VISION|1008_CITIZEN|1008|1976/09/08|4712/12/31|US|A
MERGE|PersonCitizenship|VISION|1009_CITIZEN|1009|1982/02/08|4712/12/31|US|A
METADATA|PersonEmail|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|DateFr
om|DateTo|EmailType|EmailAddress|PrimaryFlag
MERGE|PersonEmail|VISION|1008_W1|1008|1976/09/08|4712/12/31|W1|bob.smythe@oracle.com|
Y

MERGE|PersonEmail|VISION|1009_W1|1009|1982/02/08|4712/12/31|W1|Susan@oracle.com|Y
METADATA|PersonEthnicity|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|Le
gislationCode|Ethnicity|PrimaryFlag
MERGE|PersonEthnicity|VISION|1008_ETHNICITY|1008|US|1|Y
MERGE|PersonEthnicity|VISION|1009_ETHNICITY|1009|US|1|Y
METADATA|PersonNationalIdentifier|SourceSystemOwner|SourceSystemId|PersonId(SourceSys
temId)|LegislationCode|NationalIdentifierType|NationalIdentifierNumber|PrimaryFlag
MERGE|PersonNationalIdentifier|VISION|1008_NI|1008|US|SSN|123-99-0007|Y
MERGE|PersonNationalIdentifier|VISION|1009_NI|1009|US|SSN|123-99-1000|Y
METADATA|PersonPhone|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|DateFr
om|DateTo|PhoneType|PhoneNumber|PrimaryFlag
MERGE|PersonPhone|VISION|1008_W1|1008|1976/09/08|4712/12/31|W1|807.343.0302|Y
MERGE|PersonPhone|VISION|1009_W1|1009|1982/02/08|4712/12/31|W1|807.343.2352|Y
Creating a Worker with Multiple Legal Employers

This file creates a worker that has had two global transfers, changing legal employer both times. Source keys are
used so that the data can be more easily referenced for update later.
The work relationships created by this file:
ESD EED Legal Employer
16-Jun-1990 31-Dec-2000 Legal Employer 1
1-Jan-2001 31-Dec-2005 Legal Employer 2
1-Jan-2006 Legal Employer 3
Worker.dat
METADATA|Worker|SourceSystemOwner|SourceSystemId|PersonId|ActionCode|ReasonCode|EffectiveS
tartDate|EffectiveEndDate|PersonNumber|StartDate|DateOfBirth|CountryOfBirth|WaiveDataProte
ctFlag
MERGE|Worker|VISION|2035||HIRE||1990/07/16|4712/12/31|2035|1990/07/16|1943/07/12|EE|N
METADATA|PersonLegislativeData|SourceSystemOwner|SourceSystemId|EffectiveStartDate|Effecti
veEndDate|PersonId(SourceSystemId)|LegislationCode|MaritalStatus|Sex
MERGE|PersonLegislativeData|VISION|2035|1990/07/16|2005/05/08|2035|US|S|F
MERGE|PersonLegislativeData|VISION|2035|2005/05/09|4712/12/31|2035|US|M|F
METADATA|PersonName|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate|P
ersonId(SourceSystemId)|LegislationCode|NameType|FirstName|MiddleNames|LastName|KnownAs|Ti
tle
MERGE|PersonName|VISION|2035_GLOBAL|1990/07/16|2005/05/03|2035|US|GLOBAL|Janet|Anne|Wilson
||MISS
MERGE|PersonName|VISION|2035_GLOBAL|2005/05/04|4712/12/31|2035|US|GLOBAL|Janet|Anne|Butler
|Jan|MRS.
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|LegalEmployerName|PersonId(Sour
ceSystemId)|DateStart|WorkerType|LegalEmployerSeniorityDate|ActualTerminationDate|Enterpri
seSeniorityDate|LastWorkingDate|NotifiedTerminationDate|OnMilitaryServiceFlag|PrimaryFlag|
ActionCode|ReasonCode
MERGE|WorkRelationship|VISION|2035WR|Legal Employer
1|2035|1990/07/16|E||2000/12/31|1990/07/16|||N|Y|RESIGNATION|RESIGN_PERSONAL
MERGE|WorkRelationship|VISION|2035WR01|Legal Employer
2|2035|2001/01/01|E||2005/12/31|1990/07/16|||N|Y|RESIGNATION|RESIGN_PERSONAL

MERGE|WorkRelationship|VISION|2035WR02|Legal Employer
3|2035|2006/01/01|E|||1990/07/16|||N|Y|HIRE|
METADATA|WorkTerms|SourceSystemOwner|SourceSystemId|PeriodOfServiceId(SourceSystemId)|Acti
onCode|ReasonCode|LegalEmployerName|AssignmentNumber|AssignmentName|EffectiveStartDate|Eff
ectiveEndDate|EffectiveSequence|EffectiveLatestChange|PersonTypeCode|AssignmentStatusTypeC
ode|AssignmentType|BusinessUnitShortCode|PrimaryWorkTermsFlag
MERGE|WorkTerms|VISION|2035WT|2035WR|HIRE||Legal Employer
1|WT2035|WT2035|1990/07/16|2000/12/31|1|N|Employee|ACTIVE_NO_PROCESS|ET|FUSIONHCMQA|Y
MERGE|WorkTerms|VISION|2035WT|2035WR|RESIGNATION|RESIGN_PERSONAL|Legal Employer
1|WT2035|WT2035|2001/01/01|4712/12/31|1|N|Employee|INACTIVE_NO_PROCESS|ET|FUSIONHCMQA|Y
MERGE|WorkTerms|VISION|2035WT01|2035WR01|HIRE||Legal Employer 2|WT2035-1|WT2035-
1|2001/01/01|2005/12/31|1|N|Employee|ACTIVE_NO_PROCESS|ET|FUSIONHCMQA|Y
MERGE|WorkTerms|VISION|2035WT01|2035WR01|RESIGNATION|RESIGN_PERSONAL|Legal Employer
2|WT2035-1|WT2035-
1|2006/01/01|4712/12/31|1|N|Employee|INACTIVE_NO_PROCESS|ET|FUSIONHCMQA|Y
MERGE|WorkTerms|VISION|2035WT02|2035WR02|HIRE||Legal Employer 3|WT2035-2|WT2035-
MERGE|WorkTerms|VISION|2035WT02|2035WR02|ASG_CHANGE||Legal Employer 3|WT2035-2|WT2035-
METADATA|Assignment|SourceSystemOwner|SourceSystemId|WorkTermsAssignmentId(SourceSystemId)
|ActionCode|ReasonCode|LegalEmployerName|AssignmentNumber|AssignmentName|EffectiveStartDat
e|EffectiveEndDate|EffectiveSequence|EffectiveLatestChange|PersonTypeCode|AssignmentStatus
TypeCode|AssignmentType|BusinessUnitShortCode|PrimaryAssignmentFlag|FreezeStartDate|Freeze
UntilDate|PeriodOfServiceId(SourceSystemId)
MERGE|Assignment|VISION|2035ASG|2035WT|HIRE||Legal Employer
1|2035|2035|1990/07/16|2000/12/31|1|N|Employee|ACTIVE_NO_PROCESS|E|FUSIONHCMQA|Y|4712/12/3
1|1950/01/01|2035WR
MERGE|Assignment|VISION|2035ASG|2035WT|RESIGNATION|RESIGN_PERSONAL|Legal Employer
1|2035|2035|2001/01/01|4712/12/31|1|N|Employee|INACTIVE_NO_PROCESS|E|FUSIONHCMQA|Y|4712/12
/31|1950/01/01|2035WR
MERGE|Assignment|VISION|2035ASG01|2035WT01|HIRE||Legal Employer 2|2035-1|2035-
1|2001/01/01|2005/12/31|1|N|Employee|ACTIVE_NO_PROCESS|E|FUSIONHCMQA|Y|4712/12/31|1950/01/
01|2035WR01
MERGE|Assignment|VISION|2035ASG01|2035WT01|RESIGNATION|RESIGN_PERSONAL|Legal Employer
2|2035-1|2035-
1|2006/01/01|4712/12/31|1|N|Employee|INACTIVE_NO_PROCESS|E|FUSIONHCMQA|Y|4712/12/31|1950/0
1/01|2035WR01
MERGE|Assignment|VISION|2035ASG02|2035WT02|HIRE||Legal Employer 3|2035-2|2035-
01|2035WR02
MERGE|Assignment|VISION|2035ASG02|2035WT02|ASG_CHANGE||Legal Employer 3|2035-2|2035-
01|2035WR02
Loading Supervisors
It is recommended that supervisor records not be provided with the new worker data but loaded separately in a
different zip file. This will ensure that any referenced supervisor records are created in Oracle Fusion prior to
referencing them as supervisors.
You need to take into account that for every supervisor record there must be corresponding Assignment and
Employment Terms rows (either already loaded or in the dat file) that should match with the supervisor records on
EffectiveStartDate, ActionCode and ReasonCode.

Employment Terms Manager
The discriminator WorkTermsSupervisor is used to load Employment Terms Manager records using HCM Data
Loader. The following WorkTermsSupervisor attributes are commonly used when loading new supervisor records.
Other optional attributes may be available.
EMPLOYMENT TERMS ATTRIBUTES

Attribute prompt
SourceSystemId / * Assignment Number You must provide a unique reference for the record being created. Supply either a
SourceSystemOwner * Type source key or the user key attributes AssignmentNumber and ManagerType and
either the ManagerAssignmentNumber or the ManagerPersonNumber.
* Name
*1
AssignmentId * Assignment Number Unique reference to the parent employment terms. If using user keys, supply
values for these attributes: AssignmentNumber.
If using source keys, supply the value SourceSystemId value from the
employment terms record and add the source key hint to this attribute name, that
is, AssignmentId(SourceSystemId).
ManagerType * Type The role the supervisor has in the overall organization structure, such as functional
leader, project leader, and so on. This attribute is validated using the
PER_SUPERVISOR_TYPE lookup.
ManagerAssignmentId*1 * Name The unique reference to the supervisors assignment. If using user keys, supply
either the ManagerAssignmentNumber or the ManagerPersonNumber attribute.
If using source keys, supply the value SourceSystemId value for the supervisors
AssignmentId(SourceSystemId).
PrimaryFlag Set to Y if this is the primary supervisor for the worker.
ActionCode Specify the action code for this change.
ReasonCode Specify the reason for the action performed.
FLEX:PER_ASG_SUPER Only supply if loading Assignment Supervisors Attributes DFF data. The
VISOR_DF context for the DFF data is supplied against this attribute.
AssignmentNumber * Assignment Number Used to uniquely identify the parent employment terms if using user keys. The
ManagerAssignmentNum * Name The assignment number of the supervisor.

ber This is not required if you supplied an alternative key type using the
ManagerAssignmentId attribute.
ManagerPersonNumber * Name The person number of the supervisor.

This is not required if you supplied an alternative key type using the
user key.

Assignment Manager
The discriminator AssignmentSupervisor is used to load Assignment Manager records using HCM Data Loader.
The following AssignmentSupervisor attributes are commonly used when loading new supervisor records. Other
ASSIGNMENT ATTRIBUTES

Attribute prompt
SourceSystemId / * Assignment Number You must provide a unique reference for the record being created. Supply either a
SourceSystemOwner * Type source key or the user key attributes AssignmentNumber and ManagerType and
either the ManagerAssignmentNumber or the ManagerPersonNumber.
* Name
*1
AssignmentId * Assignment Number Unique reference to the parent assignment. If using user keys supply values for
these attributes: AssignmentNumber
If using source keys supply the value SourceSystemId value from the assignment
record and add the source key hint to this attribute name, that is,
ManagerType * Type The role the supervisor has in the overall organization structure, such as functional
leader, project leader, and so on. This attribute is validated using the
PER_SUPERVISOR_TYPE lookup.
ManagerAssignmentId*1 * Name The unique reference to the supervisors assignment. If using user keys supply
either the ManagerAssignmentNumber or the ManagerPersonNumber attribute.
If using source keys supply the value SourceSystemId value for the supervisors
PrimaryFlag Set to Y if this is the primary supervisor for the worker.
ActionCode Specify the action code for this change.
ReasonCode Specify the reason for the action performed.
FLEX:PER_ASG_SUPER Only supply if loading Assignment Supervisors Attributes DFF data. The
VISOR_DF context for the DFF data is supplied against this attribute.
AssignmentNumber * Assignment Number Used to uniquely identify the parent assignment if using user keys. The
assignment number for the assignment.
ManagerAssignmentNum * Name The assignment number of the supervisor.

ber This is not required if you supplied an alternative key type using the
ManagerPersonNumber * Name The person number of the supervisor.

This is not required if you supplied an alternative key type using the
user key.

Figure 11: Manager Details
Updating Existing Workers

You will update existing workers when you need to perform an incremental data load, including integration with
external systems.
In dealing with the date-effective history, you need to consider how HCM Data Loader works regarding future-dated
records, as you want to retain the existing date-effective occurrences.
Update Modes
HCM Data Loader supports two different update modes that impact how future dated records are handled:
Retain - Retains all existing date-effective records. This mode is recommended when you are supplying an
incremental update to an existing record.
Replace - Removes existing date-effective splits for the date range specified. This mode is useful during
data migration, when you are uploading the complete data for a record.
The mode can be controlled with a SET command:

SET PURGE_FUTURE_CHANGES <value>
Where either Y (Replace) or N (Retain) can be supplied.
It is recommended that you make use of the #NULL command for attributes that should have a null value. Leaving
attribute values unspecified will ensure existing attribute values are retained. For more information and examples of
this behavior, see the HCM Data Loader Users Guide.
When HCM Data Loader is running in retain mode, you can choose to:
Retain future dated record values without updating them
Retain future date-effective splits but roll forward the changed values
The possibility to roll forward the changed values to subsequent occurrences is a very powerful feature that must be
used with care. As some of the worker components make use of actions and reasons to classify the data changes,
you must consider that rolling forward the action and reason of a data change to the subsequent records is very
seldom appropriate.
Retaining Future Dated Record Values

If you want any future dated changes to be retained unchanged, then instead of supplying an Effective End Date,
use the #RETAIN tag. This will ensure that your change will only take effect until the next date-effective record. If
there are no future dated records, your change will continue until the end-date of the record, usually the end of time.

Assignment Example
CURRENT ASSIGNMENT OBJECT
ESD Seq EED Action Code Job Grade Location Normal Hours
2010/06/08 1 2012/03/03 HIRE ACC1 IC2 HQ 40
2012/03/04 1 2012/03/04 PROMOTION ACC1 IC4 HQ 40
2012/03/04 2 2012/03/04 TRANSFER ACC1 IC4 LVP 40
2012/03/04 3 2012/06/01 JOB_CHANGE ACC3 IC4 LVP 40
Update the working hours on the 10th Jan 2012 retaining future dated values
SET PURGE_FUTURE_CHANGES N
METADATA|Assignment|SourceSystemId|EffectiveStartDate|EffectiveSequence|Effecti
veLatestChange|EffectiveEndDate|ActionCode|NormalHours
MERGE|Assignment|2724|2012/01/10||Y|#RETAIN|ASG_CHANGE|37.5
NEW ASSIGNMENT OBJECT
2010/06/08 1 2012/01/09 HIRE ACC1 IC2 HQ 40
2012/01/10 1 2012/03/03 ASG_CHANGE ACC1 IC2 HQ 37.5
2012/03/04 1 2012/03/04 PROMOTION ACC1 IC4 HQ 40
2012/03/04 2 2012/03/04 TRANSFER ACC1 IC4 LVP 40
Note: The EffectiveSequence attribute was not supplied with a value to ensure the next MCPD split was assigned to
this change. If you want to start at an existing MCPD split, specify the EffectiveSequence and
EffectiveLatestChange values for that MCPD record.
ATTENTION: This is the only recommended action for MCPD records, or any record with a mandatory ActionCode.
By attempting to roll forward any changes over future dated records, you are likely to corrupt the ActionCode for
each future dated record in your specified date range.
If you had not supplied the #RETAIN tag, but instead left the EffectiveEndDate unspecified or had a value of
4712/12/31, to ensure the change was applied until the end of time, you would get a very different result:
Update the working hours on the 10th Jan 2012 overwriting future dated values:
METADATA|Assignment|SourceSystemId|EffectiveStartDate|EffectiveSequence|Effecti
veLatestChange|EffectiveEndDate|ActionCode|NormalHours
MERGE|Assignment|2724|2012/01/10||Y||ASG_CHANGE|37.5

NEW ASSIGNMENT OBJECT
2010/06/08 1 2012/01/09 HIRE ACC1 IC2 HQ 40
2012/03/04 2 2012/03/04 ASG_CHANGE ACC1 IC4 LVP 37.5
As the Action Code is a mandatory attribute that you have supplied a value for, the supplied value will overwrite the
existing Action Code for all future dated records.
Note: This action is not reversible. If you supply attribute values that span existing date-effective splits they will all be
corrected with every attribute value supplied.
In the following paragraphs, you can find how specific operations can be performed while updating existing workers.
Work Relationship Changes

The worker object provides several flags that simplify work relationship actions, such as termination, global transfer,
and changing the primary assignment. These flags are not supported when supplying full date-effective history.
They are provided to support on-going maintenance of the Oracle HCM Cloud data.
The flags are provided for independent actions. You cannot provide multiple flags on the same work relationship
record. For example, you cannot both terminate a work relationship (TerminateWorkRelationshipFlag) and perform a
global transfer (GlobalTransferFlag) on the same work relationship at the same time.
Changing the Hire Date

To change the hire date, which is the start date of a work relationship, the new date should be provided in the
NewStartDate of the work relationship. Only the work relationship record needs to be supplied to change the hire
date; the work terms and assignment records will be maintained automatically.
Worker.dat
This file alters the hire date for an existing worker.
egalEmployerName|NewStartDate
MERGE|WorkRelationship|VISION|1009_POS|1009|Cox-6-CWB|2002/02/10
Terminating a Work Relationship

To terminate a work relationship supply the work relationship record with a TerminateWorkRelationshipFlag attribute
value of Y and specify the date for the termination against the ActualTerminationDate attribute.

Worker.dat
This file terminates a work relationship.
egalEmployerName|TerminateWorkRelationshipFlag|ActualTerminationDate|ActionCode|Reaso
nCode
MERGE|WorkRelationship|VISION|1009_POS|1009|Cox-6-
CWB|Y|2015/10/02|RESIGNATION|RESIGN_PERSONAL
After the termination date of the work relationship, all the assignment records will have an inactive assignment
status type.
Correcting a Terminated Work Relationship

A terminated work relationship will be corrected based on the new ActualTerminationDate supplied. For correcting a
work relationship termination, the CorrectTerminationFlag attribute must be set to Y.
Worker.dat
This file corrects the termination date for a terminated work relationship.
egalEmployerName|CorrectTerminationFlag|ActualTerminationDate
MERGE|WorkRelationship|VISION|1009_POS|1009|Cox-6-CWB|Y|2015/10/08
Reversing a Termination
A terminated work relationship can be reversed by supplying the work relationship with a ReverseTerminationFlag
attribute set to Y.
Worker.dat
This file reverses the termination of a work relationship.
egalEmployerName|ReverseTerminationFlag
MERGE|WorkRelationship|VISION|1009_POS|1009|Cox-6-CWB|Y
Canceling a Work Relationship

A work relationship can be cancelled by supplying the work relationship with a CancelWorkRelationshipFlag attribute
set to Y. Use the DELETE instruction with this flag.
Worker.dat
This file deletes the specified work relationship and all its child records.
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|C
ancelWorkRelationshipFlag
DELETE|WorkRelationship|VISION|1008_POS|1008|Y

Changing the Primary Assignment
When you supply a primary work relationship, the existing primary work relationship will be converted into a
nonprimary automatically, on the date provided in the attribute DateForPrimaryFlagChange.
To make a nonprimary work relationship primary, you need only to supply the work relationship that is to be made
primary with the PrimaryFlag attribute set to Y. The date from which the work relationship is to be made primary
should be provided in the DateForPrimaryFlagChange attribute. The corresponding changes to work terms and
assignment are maintained automatically. The primary flag for the existing primary work relationship will be set to N
automatically.
Performing a Global Transfer

A global transfer is a permanent transfer from one legal employer to another. It results in the termination of an
existing work relationship and the creation of a new one. The termination date of the existing work relationship will
be one day prior to the start date of the new work relationship.
The global transfer can be applied to both primary and nonprimary work relationships, with some difference in the
use. By default, the global transfer will be applied to the primary work relationship.
In order to perform a global transfer, you provide the new work relationship with all its child components. The work
relationship must be supplied with:
A GlobalTransferFlag attribute set to Y
An ActionCode that belongs to the EMPL_GLB_TRANSFER action type
A DateStart that is the date of the global transfer
Do not include the work relationship being terminated.
The termination and the creation of the work relationship will be subject to validation to ensure data consistency. In
particular, a worker cannot be left with only an active nonprimary work relationship. Therefore, if the worker has two
active work relationships, you cannot perform the global transfer on the primary one.
Performing a Global Transfer on a Nonprimary Work Relationship
As a worker can have multiple nonprimary work relationships, when you perform a global transfer of a nonprimary
work relationship you must supply additional information so that the correct existing work relationship is terminated
To perform the global transfer on a nonprimary work relationship, you must supply:
The parent worker record in the dat file.
The nonprimary work relationship that you intend to terminate. Do not supply:
o Any child records for the terminated work relationship
o The GlobalTransferFlag attribute
Example of global transfer for a primary work relationship:

Worker.dat
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|
LegalEmployerName|DateStart|WorkerType|PrimaryFlag|GlobalTransferFlag
MERGE|WorkRelationship|HRC_SQLLOADER|WR-HDLWorker_111_1|HDLWorker_111_1|Vision
Corporation|1985/07/16|E|Y|Y
METADATA|WorkTerms|SourceSystemOwner|SourceSystemId|ActionCode|ReasonCode|LegalEmplo
yerName|EffectiveStartDate|EffectiveEndDate|EffectiveLatestChange|EffectiveSequence|
PeriodOfServiceId(SourceSystemId)|PersonTypeCode|AssignmentStatusTypeCode|Assignment
Type|BusinessUnitId|NoticePeriod|PrimaryWorkTermsFlag|FreezeStartDate|FreezeUntilDat
e
MERGE|WorkTerms|HRC_SQLLOADER|WT-HDLWorker_111_1|HIRE||Vision
Corporation|1985/07/16|4712/12/31|N|1|WR-
HDLWorker_111_1|Employee|ACTIVE_NO_PROCESS|ET|202|0|Y|4712/12/31|1950/01/01
METADATA|Assignment|SourceSystemOwner|SourceSystemId|ActionCode|ReasonCode|LegalEmpl
oyerName|EffectiveStartDate|EffectiveEndDate|EffectiveLatestChange|EffectiveSequence
|PeriodOfServiceId(SourceSystemId)|WorkTermsAssignmentId(SourceSystemId)|PersonTypeC
ode|AssignmentStatusTypeCode|AssignmentType|BusinessUnitId|NoticePeriod|PrimaryAssig
nmentFlag|FreezeStartDate|FreezeUntilDate
MERGE|Assignment|HRC_SQLLOADER|WA-HDLWorker_111_1|HIRE||Vision
Corporation|1985/07/16|4712/12/31|N|1|WR-HDLWorker_111_1|WT-
HDLWorker_111_1|Employee|ACTIVE_NO_PROCESS|E|202|0|Y|4712/12/31|1950/01/01
Example of global transfer for a nonprimary work relationship:
Worker.dat
METADATA|Worker|SourceSystemOwner|SourceSystemId|PersonId|EffectiveStartDate|Effectiv
eEndDate|StartDate|DateOfBirth|CountryOfBirth|WaiveDataProtectFlag
MERGE|Worker|HRC_SQLLOADER|HDLWorker_111_1||1973/03/12|4712/12/31|1992/11/29|1967/12/
06|EE|N
egalEmployerName|DateStart|WorkerType|PrimaryFlag|GlobalTransferFlag
Corporation|1973/03/12|E||
Corporation|1985/07/16|E||Y
METADATA|WorkTerms|SourceSystemOwner|SourceSystemId|ActionCode|ReasonCode|LegalEmploy
erName|EffectiveStartDate|EffectiveEndDate|EffectiveLatestChange|EffectiveSequence|Pe
riodOfServiceId(SourceSystemId)|PersonTypeCode|AssignmentStatusTypeCode|AssignmentTyp
e|BusinessUnitId|NoticePeriod|PrimaryWorkTermsFlag|FreezeStartDate|FreezeUntilDate
MERGE|WorkTerms|HRC_SQLLOADER|WT-HDLWorker_222_1|HIRE||Vision
Corporation|1985/07/16|4712/12/31|N|1|WR-
HDLWorker_222_1|Employee|ACTIVE_NO_PROCESS|ET|202|0|Y|4712/12/31|1950/01/01
METADATA|Assignment|SourceSystemOwner|SourceSystemId|ActionCode|ReasonCode|LegalEmplo
yerName|EffectiveStartDate|EffectiveEndDate|EffectiveLatestChange|EffectiveSequence|P
eriodOfServiceId(SourceSystemId)|WorkTermsAssignmentId(SourceSystemId)|PersonTypeCode
|AssignmentStatusTypeCode|AssignmentType|BusinessUnitId|NoticePeriod|PrimaryAssignmen
tFlag|FreezeStartDate|FreezeUntilDate
MERGE|Assignment|HRC_SQLLOADER|WA-HDLWorker_222_1|HIRE||Vision
Corporation|1985/07/16|4712/12/31|N|1|WR-HDLWorker_222_1|WT-
HDLWorker_222_1|Employee|ACTIVE_NO_PROCESS|E|202|0|Y|4712/12/31|1950/01/01

Example of an external identifier:
Worker.dat
METADATA|ExternalIdentifier|ExternalIdentifierNumber|PersonNumber|ExternalIdentifierT
ype|ExternalIdentifierSequence
MERGE|ExternalIdentifier|rtyui45678|TestPer0TALTEST_9|Third-Party Payroll ID|1
When you perform a global transfer, the new work relationship may have a legislation code that is new for the
person. In this case, you could also update the legislation code for the person name with the new legislation code.
The person-name legislation code is validated against all available work-relationship legislation codes. Therefore,
the change to the work relationship must occur before the change to the person name. To update the legislation
code in the person name, you can:
1. Provide the worker object with no change in the same .dat file as the person name and work relationship
changes. The whole worker object is treated as one logical record, and work relationship changes are
processed before person name changes.
2. Process the work relationship update first and the person name update second.
Post-Load Processes
After an initial or incremental load of worker records, you run a set of processes to complete data setup in the Oracle
HCM Cloud environment. You run these processes in the following order from the Scheduled Processes work area:
Synchronize Person Records

When you run the Synchronize Person Records process, changes to person and assignment details that
have occurred since the last data load are communicated to consuming applications, such as Oracle
Fusion Trading Community Model and Oracle Identity Management, in the Oracle Fusion environment.
Refresh Manager Hierarchy

For performance reasons, the complete manager hierarchy for each person is extracted from live data
tables and stored in a separate manager hierarchy table, known as the denormalized manager hierarchy; it
ensures that a person's manager hierarchy is both easily accessible and up to date. The Refresh Manager
Hierarchy process populates the denormalized manager hierarchy table with latest information after each
data load.
Update Person Search Keywords

Several attributes of person, employment, and profile records are used as person-search keywords. This
process copies keyword values from the originating records to the PER_KEYWORDS table, where they
are indexed to improve search performance. When you run the Update Person Search Keywords process,
the whole PER_KEYWORDS table is refreshed; therefore, you are recommended to run the process at
times of low activity to avoid performance problems.
After loading worker data, you must run the ESS job in order to be able to correctly search persons in the
Person Search user interface.
Deletion Support for Worker

You can delete child records using HCM Data Loader, but not an entire Worker.

The reason a complete person deletion is not available is because the person object is an integral part of the
application and there can be many references to it from other applications, including integrations with Taleo.
Deleting the person would cause referential data integrity issues that would jeopardize the functionality of the
application.
The table below details which components of the Worker hierarchy can be deleted and provides recommendations
about deleting records using HCM Data Loader.
Delete
Discriminator Recommendations
Supported
Worker No You cannot delete the entire worker.
ExternalIdentifier Yes
PersonAddress Yes You can delete addresses, but not the primary address.
PersonCitizenship Yes
PersonDeliveryMethod Yes
PersonDriversLicence Yes
PersonEmail Yes You can delete all email addresses, regardless of the email type or primary
status. However, if you delete just the primary email address and other email
address is to be retained, you must first update one of the remaining email
addresses as primary.
PersonEthnicity Yes
PersonImage Yes
PersonLegislativeData Only if multiple There must always be one legislative data record for a worker, additional
records can be deleted.
PersonName No You cannot delete a workers name.
PersonNationalIdentifier Yes
PersonPassport Yes
PersonPhone Yes
PersonReligion Yes
PersonVisa Yes
PersonUserInformation No This is only available when creating new workers, and is not applicable for
deleting users.
PersonUserManualRoles No This is only available when creating new workers, and is not applicable for
removing roles. Refer to the Loading Update User Requests using HCM Data
Loader white paper to remove roles from existing users.
WorkRelationship Cancel When deleting a work relationship, you must also supply the
CancelWorkRelationshipFlag with a value of Y. For more information, see the
Canceling a Work Relationship section.
WorkTerms No You cannot delete an individual work terms record.
Assignment No You cannot delete an individual assignment record.
AssignmentGradeSteps Yes
AssignmentSupervisor Yes

Delete
Discriminator Recommendations
Supported
AssignmentWorkMeasure Yes
AssignmentExtraInfo Yes
Contract No
WorkTermsGradeSteps Yes
WorkTermsSupervisor Yes
WorkTermsWorkMeasure Yes
WorkTermsExtraInfo Yes
WorkerExtraInfo Yes

Oracle Corporation, World Headquarters Worldwide Inquiries
500 Oracle Parkway Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA Fax: +1.650.506.7200
CONNECT W ITH US
blogs.oracle.com/oracle Copyright 2014, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
facebook.com/oracle fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
twitter.com/oracle means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
oracle.com
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0317
Loading Worker using HCM Data Loader

March 2017

Loading Worker Using H CM Data Loader

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Loading Worker Using H CM Data Loader

Cargado por

Copyright:

Formatos disponibles

Loading Worker

Using HCM Data Loader V1.4

Oracle Fusion Human Capital Management 11g Release 9 (11.1.9)

LOADING WORKER USING HCM DATA LOADER

2 | LOADING WORKER USING HCM DATA LOADER

How to Use the Information in This Document

Considerations and Prerequisites What to consider before attempting to load data

1 | LOADING WORKER USING HCM DATA LOADER

July 2016 1.0 Added details on external identifiers.

March 2017 1.4 Added information about correcting person numbers.

2 | LOADING WORKER USING HCM DATA LOADER

Considerations and Prerequisites for Worker

3 | LOADING WORKER USING HCM DATA LOADER

Oracle Fusion Human Capital Management Employment Model Overview

2 Tier Employment Model

4 | LOADING WORKER USING HCM DATA LOADER

3 Tier Employment Model

Configuration of the Employment Model

5 | LOADING WORKER USING HCM DATA LOADER

Supported employment models:

2 Tier Multiple Assignment (2NTMA)

Other Configuration Options for the Employment Model

Allow Employment Terms

6 | LOADING WORKER USING HCM DATA LOADER

Actions / Action Reasons Framework

7 | LOADING WORKER USING HCM DATA LOADER

Assignment Status Types

Earliest Effective Start and Last Effective End Date Recommendations

Component Earliest Effective Start Date Last Effective End Date

Worker Earliest start date of the worker. The end of time.

8 | LOADING WORKER USING HCM DATA LOADER

Person Legislative Data

9 | LOADING WORKER USING HCM DATA LOADER

Provisioning Roles to Users

10 | LOADING WORKER USING HCM DATA LOADER

Component Functional Description Discriminator

Person Address Address for a Worker. PersonAddress

Person Drivers Driving license details for a worker. PersonDriversLicense

11 | LOADING WORKER USING HCM DATA LOADER

Assignment The extensible flexfield data for the Assignment. AssignmentExtraInfo

Loading New Workers

12 | LOADING WORKER USING HCM DATA LOADER

Contracts cannot be loaded individually.

You can setup different behaviors for user account generation.

13 | LOADING WORKER USING HCM DATA LOADER

The mode can be controlled with a SET command:

HCM Data Loader

EffectiveEndDate If left blank this will default to the end of time.

StartDate * Hire Date The hire date for the worker.

ActionCode * Hire Action The action performed, for example HIRE.

ReasonCode * Hire Reason Optional, the reason for the action.

DateOfBirth Date of Birth The date of birth.

14 | LOADING WORKER USING HCM DATA LOADER

Figure 1: Hire an Employee

15 | LOADING WORKER USING HCM DATA LOADER

PERSON NAME ATTRIBUTES

HCM Data Loader

LastName * Last Name The persons last name.

FirstName First Name The persons first name.

MiddleNames Middle Name The persons middle names.

16 | LOADING WORKER USING HCM DATA LOADER

PreviousLastName The persons previous last name.

Figure 2: Personal Details