Beruflich Dokumente
Kultur Dokumente
Q4 2016 Release
Document Version: Q1 2017 – 2017-03-16
2 Advances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.1 AdvancesAccumulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
2.2 AdvancesEligibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.3 NonRecurringPayment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3 Apprentice Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.1 Apprentice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
3.2 ApprenticeEventType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.3 ApprenticeInternalTrainingEvent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.4 ApprenticePracticalTrainingEvent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.5 ApprenticeSchool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.6 ApprenticeSchoolEvent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5 Deductions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.1 DeductionScreenId. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2 OneTimeDeduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.3 RecurringDeduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
15 FAQs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
15.1 Admin Access to OData: What does it mean?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
15.2 Authentication Types: Which one is right for me?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Authentication Types for OData API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
15.3 API: Do I use OData or Compound Employee API for EC entities?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
15.4 Broken APIs: What causes them?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .602
15.5 Error message: Behavior in upsert statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
15.6 Inactive users: Do EC OData APIs ignore them?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .604
15.7 Performance: How to improve it. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
15.8 Roundtrips: Why are there errors in some upserts?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
15.9 Side effect: What is it?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
15.10 $filter: How does it work with fromDate?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Q1 2017
Table 1: The following table summarizes changes to this guide for the Q1 2017 release.
EmpJob updated Information on how to use picklist lo EmpJob [page 152]
cales correctly in $filter and avoid dupli
cate records
Duplicate Records? Contains possible reasons for duplicate Duplicate Records? [page 607]
records and how to resolve them
Initial Publication
PersonEmpTerminationInfo A new entity for getting the latest termi PersonEmpTerminationInfo [page 474]
nation date of an employee
Q4 2016
Table 2: The following table summarizes changes to this guide for the Q4 2016 release.
December 5, 2016
Provisioning setting for Admin Mode in No provisioning setting is required for Getting users up and running: Provision
Employee Central Foundation OData the Admin Mode so the provisioning set ing [page 18]
APIs corrected ting has been removed
FOWfConfigStepApprover A new entity for getting more detailed FOWfConfigStepApprover [page 217]
workflow configurations.
PersonKey A new entity for retrieving the person PersonKey [page 499]
UUID.
wfStepApproverNav Added to FOWfConfig, you can use this Using wfStepApproverNav for more de
nav to navigate to FOWfConfigStepAp tailed workflow configuration informa
prover. In FOWfConfigStepApprover the tion [page 582]
fields actionType, approverRole, appro
verType, context, relationshipToAp
prover, respectRBP, skipType, and step
Num are visible so you can use them for
detailed workflow configuration informa
tion. Up to now, these fields were only
available in FOWfConfig and they were
not visible.
PerAddressDELF Information about how to filter out exter PerAddressDEFLT [page 469](Updated
nal or internal user data, and include ex with a link to Filtering out external user
ternal and internal user data has been data [page 574])
added.
PerEmail Information about how to filter out exter PerEmail [page 472](Updated with a
nal or internal user data, and include ex link to Filtering out external user data
ternal and internal user data has been [page 574])
added.
PerPerson Information about how to filter out exter PerPerson [page 483](Updated with a
nal or internal user data, and include ex link to Filtering out external user data
ternal and internal user data has been [page 574])
added.
PerPersonal Information about how to filter out exter PerPersonal [page 487](Updated with a
nal or internal user data, and include ex link to Filtering out external user data
ternal and internal user data has been [page 574])
added.
PerPhone Information about how to filter out exter PerPhone [page 494](Updated with a
nal or internal user data, and include ex link to Filtering out external user data
ternal and internal user data has been [page 574])
added.
Getting users up and running: Permis Previously,it had been stated that the Getting users up and running: Permis
sion Settings permission setting Admin Access to sion settings [page 19]
OData API was a prerequisite permission
setting for accessing OData APIs. This is
wrong and has been removed.
Getting users up and running: Authenti Explains the different authentication Getting users up and running: Authenti
types available. Also clarifies that the
cation Types cation types [page 21]
permission setting Admin Access to
OData API is the setting required for one
of these authentication types, Basic Au
thorization
Filtering out external user data Explains how to use the Boolean fields Filtering out external user data [page
isECRecord and includeAllRecords to fil 574]
ter out external or internal user data. Or,
in some cases how to include external
and internal user data.
Exposing person UUID for integration Explains the new concept of a person Exposing person UUID for intergration
and import scenarios UUID and how you can use it. and import scenarios [page 579]
Using wfStepApproverNav for more de Explains how you can access more fields Using wfStepApproverNav for more de
for workflow configuration information
tailed workflow configuration informa tailed workflow configuration informa
tion tion [page 582]
Admin Access to OData: What does it Explains that this permission setting Admin Access to OData: What does it
mean?
grants the user basic authorization. mean? [page 593]
Authentication Types: Which one is right When you choose an authentication Authentication Types: Which one is right
for me? type, you need to consider questions for me? [page 593]
such as the level of security you need
Authentication Types for OData API
and whether or not users are accessing a
[page 593]
productive or test system.
HTTP Basic Authorization [page 594]
Table 3: The following table summarizes changes to this guide for the Q3 2016 release.
August 5
SecondaryAssignments You can use this entity SecondaryAs SecondaryAssignments [page 177]
signments along with the child entity
secondaryAssignmentsItems SecondaryAssignmentsItem [page 182]
secondaryAssignmentsItems to differen
tiate primary from secondary employ
ments during concurrent employment
scenarios
Differentiating primary from secondary Take a look at this topic to get a deep Differentiating primary from secondary
employment during concurrent employ dive into using the new entities, Secon employment during concurrent employ
ment replication daryAssignment and secondaryAssign ment replication [page 587]
mentsItems during concurrent employ
ment replication.
fileLocale This new url parameter lets you avoid lo fileLocale [page 53]
cale conflicts when upserting data.
FAQs section We've introduced this section to give you Error message: Behavior in upsert state
a quick point of reference to topics such ments [page 603]
as side effects, inactive users, avoiding
API: Do I use OData or Compound Em
roundtrip consistencies, and much more.
ployee API for EC entities? [page 601]
PaymentInformationDetailV3ZAF Here you can get the information on the Example: PaymentInformationDe
payment information screen for South tailV3ZAF [page 457]
Africa (ZAF).
Table 4: The following table summarizes changes to this guide for the Q2 2016 release. We've also listed the enhancements that
have not resulted in a documentation update so that you still have a picture of what is new in this release. You can see these
enhancements in the row Overview of Updates.
New Section Date Handling for Employee Gives you lots of background information Date Handling for Employee Central Enti
Central Entities about the parameters we use for dating, ties [page 34]
what and and how effective dating works
as well as detailed examples on multiple
changes per day and last modified quer
ies to name but a few.
Q1 2016
Table 5: The following table summarizes changes to this guide for the Q1 2016 release
New Section Apprentice Management Lists the entities now available for Ap Apprentice Management [page 93]
prentice Management
Advances Lists the entities available for Advances. Advances [page 57]
Previously published in the OData API
Reference guide. Moved here due to re
organized product taxonomy.
Deductions Lists the entities available for Deduc Deductions [page 111]
tions. Previously published in the OData
API Reference guide. Moved here due to
reorganized product taxonomy.
February 8, 2016
Update to Getting users up and running: You no longer need to have PS switch on Getting users up and running: Provision
Provisioning Employee Central OData APIs in Provi
ing [page 18]
sioning.
Getting Your Time Zones Right Explains how you can tell which entity Getting your time zones right [page 21]
fields are based on UTC, which ones are
based on the server time, and why you
need to know the difference.
Global Benefits Objects Section You can see what APIs are currently Global Benefits Objects [page 309]
available for Global Benefits in this new
BenefitInsurancePlan [page 392]
section.
BenefitInsurancePlanEnrollmentDetails
[page 395]
BenefitInsuranceDependentDetail [page
399]
BenefitInsuranceEnrolleeOptions [page
407]
BenefitInsuranceRateChartEnrollee
[page 413]
BenefitInsuranceRateChartFixedAmount
[page 415]
BenefitInsuranceCoverageOptions [page
418]
BenefitInsuranceCoverageDetails [page
420]
BenefitInsuranceEnrolleeType [page
423]
Time & Attendance Management Sec You can see what APIs are currently Time Off Objects [page 501]
tion available for Time & Attendance Man
AccrualCalculationBase [page 501]
agement in this new section.
AvailableTimeType [page 504]
The WfRequest entity has been modified This new field, "url" is a deeplink URL and WfRequest [page 546]
by the addition of a new field. supports certain integration scenarios.
Welcome to the world of Employee Central OData APIs. With the help of this guide, you'll get to know what APIs we
offer, see some sample queries as well as use cases, and other information so that you can get the best out of your
Employee Central product.
With the wealth of information that your Employee Central system stores from your company’s organization, pay,
job structures, and employees, to name but a few, you’ll be able to use these OData APIs to expose the information
you need.
If you're an expert, you can skip the rest of this section and go straight to the entity that interests you. But,
whether you’re an expert or a novice, please take a minute to look at the What's New in This Guide [page 8] to get
up to speed on our latest developments.
If you're new to the topic of OData APIs, make sure that you have the HCM Suite OData API Programmer's Guide to
hand. These general programming guidelines walk you through the key concepts of OData including
authentication, query and operation types to name but a few.
In this guide take a look at Getting Started [page 15] to get a feel for the what and how of Employee Central
OData APIs, understand some basic concepts as well as know why an Employee Central OData APIs would be your
tool of choice. The section Getting users up and running: Permission settings [page 19]will tell you what
authorizations users need and you can see what Provisioning is required in this section here Getting users up and
running: Provisioning [page 18]
And last but not least, make sure you have the Employee Central Master Implementation Guide to refer to for
in-depth information about our products.
If you find anything missing from this guide, don't hesitate to get in touch with us so that we can fix it:
mailto:SuccessFactorsDocumentation@sap.com
If you're new to Employee Central OData APIs, and the world of APIs in general, the information in this section may
be useful. It explains some key concepts such as what you will need to use this guide in the first place, the entities,
when to use and not to use Employee Central OData APIs as well as different user modes to name but a few.
● Employee Objects
Comprises personal and employment details for employees, referred to as Person Objects and Employment
Objects in this guide.
Employee Central stores data in table structures which are known as entities. Entities are grouped together in
objects.
Employee Central entities let you create and manipulate employee data. Navigations in an entity represent
associations between entities. Each entity can have the following properties.
The section Employee Central Entity Properties [page 47] explains the properties in more detail and the section
Entity Association & Navigation [page 29] describes how the navigation works between entities.
The Employee Central OData API exposes the Employee Central entities and this includes foundation objects,
Personal, Employment, and MDF objects.
The Employee Central OData API supports metadata query, entity query and upsert query for these objects.
Metadata All users belonging to a company will get the same metadata query results. Results are not
Query determined by the RBP permissions for EC entities.
https://<hostname>/odata/v2/$metadata
Entity Query (Operation Most FO objects and person/employment related entities support OData query. For
GET) details, check the OData API dictionary or the results of the metadata operation.
MDF Objects
When the Employee Central OData API uses MDF objects, the following operations are supported:
Related Information
We recommend using Employee Central OData APIs if one or more of these factors applies to your situation:
Note
Don't use our OData APIs when:
● Your system cannot consume either OData APIs or SOAP for an initial data load. In this case, you would go
for Import/Export with a CSV. Automation via FTP would also be a possibility.
● You need employee replication field level delta, snapshot, or read modified employees only, then SOAP
Compound API is your tool of choice. You can find more information in the User Guide: Implementing the
Employee Central Compound Employee API .
There are two modes in Employee Central OData APIs which determine what a user or user group (in this context a
user and user group will be treated as one and the same) is authorized to view or do.
● User Mode
Assigned RBP settings determine what entities can be viewed and what can be done with them. You will
sometimes see the term RBP mode but in this guide, we use the term User Mode.
● Admin Mode
Allows full access to Employee Central OData API entities and operations. You will only use this in a limited
number of cases chiefly technical integrations. Admin Mode overrides any RBP (role based permission)
settings that have been made. You will sometimes see the term technical user, or non-RBP mode but in this
guide we use the term Admin Mode.
Note
Please note that full access means just that - Access. Upsert authorization is an additional authorization as
described in the section Getting users up and running: Permission settings [page 19].
EC OData APIs are part of Employee Central so you do not need to make any settings in Provisioning. If you want
to disable EC OData APIs then you'll need Professional Services to do this in Provisioning.
Don't forget that you will also need business-specific provisioning in addition to these settings. For example if
you're using Global Assignment, this will need to be set in provisioning. You'll find more information in the
dedicated implementation guides for your feature and they're available on https://help.sap.com/hr_ec/
The use of permission settings means that assigning users the authorizations they require for Employee Central
OData APIs is a very straightforward process. You make both your entity-specific RBP settings and other OData
API settings in one and the same place in the Admin Center using the tool Manage Permission Roles.
Tell Me More
Take a look at the following information. The tables are grouped by different entities and what the user needs to be
able to do (Authorization/Action) with those entities. Remember to read any additional information for the
permission setting that is available in your system.
User Mode No additional settings are needed. Takes into account RBP set
tings.
Upsert Administrator Permissions Employee Central API Overrides any RBP settings
Employee Central HRIS OData API (editable) made for the user and lets the
user upsert that is import infor
mation into your instance. Only
available as an Admin Mode.
Admin Mode Administrator Permissions Employee Central API Overrides any RBP settings
Employee Central HRIS OData API (read-only) made for the user but upsert
authorization needs to be given
in addition to this.
User Mode No additional settings are needed. Takes into account RBP set
tings.
Upsert Administrator Permissions Employee Central API Overrides any RBP settings
Employee Central Foundation OData API (editable) made for the user and lets the
user upsert that is import infor
mation into your instance. Only
available as an Admin Mode.
Admin Mode Administrator Permissions Employee Central API Overrides any RBP settings
Employee Central Foundation OData API (read-only) made for the user but upsert
authorization needs to be given
in addition to this.
User Mode (query only) Administrator Permissions Metadata Framework Read/ Takes into account RBP set
Write Permission on Metadata Framework tings.
Admin Mode (includes up Administrator Permissions Metadata Framework Admin Overrides any RBP settings
sert as well as query) Acces to MDF OData API made for the user.
Take a look at this table in case you need to arrange access to picklist management, SOAP APIs, API tools, or even
restrict access.
Table 9:
and
Related Information
To decide which authentication type best matches your business requirements, take a look at Authentication
Types: Which one is right for me?Authentication Types: Which one is right for me? [page 593]
It’s crucial that you do not mix and match the different time zones otherwise you’ll end up with inconsistencies so
please take a minute to familiarize yourself with how we handle time zones. Different fields, for example,
<lastmodifedDateTime>,< lastmodifiedDate>, and so on represent different time zones and you need to be
able to tell the difference.
Recommendation
To avoid inconsistencies, we recommend that you always use the UTC time zone.
To know which field is in which time zone, you also need to know the oData protocol type that supports the field.
We use:
Usually, but not always, the following fields are of the type Edm.DateTime and are in the server time zone.
● <createdDate>
● <createdOn>
● <lastModifiedDate>
● <lastModifiedOn>
Examples of exceptions
Here are few examples of exceptions where the fields createdDate, createdOn, or lastModifiedDate are not of the
type Edm.DateTime but are of the type Edm.DateTimeOffset.
You must be sure to check entities on a case-by-case basis yourself. This list of exceptions is not exhaustive.
Attachment createdDate
Background_* lastModifiedDate
Edm.DateTimeOffset (=UTC)
Usually, but not always, the following fields are of the type Edm.DateTimeOffset and are in the UTC time zone.
● <createdDateTime>
● <lastModifiedDateTime>
● <lastModifiedDatewithTZ>
● < lastModifiedWithTZ>
Although there are currently no known exceptions to this rule, we recommend that you check the entities on a
case-by-case basis yourself.
Example: PerPhone
Take a look at the snippet of code below – here you can clearly see that the different time zones are available in the
entity as represented by the <createdOn>, <createdDateTime>,< lastModifiedOn>, and
<lastModifiedDateTime>.
Sample Code
<m:properties>
<d:personIdExternal>achin1</d:personIdExternal>
<d:phoneType>5845</d:phoneType>
<d:extension m:null="true" />
<d:createdOn m:type="Edm.DateTime">2011-03-17T21:39:02</d:createdOn>
<d:isPrimary m:type="Edm.Boolean">true</d:isPrimary>
<d:phoneNumber>661 2000</d:phoneNumber>
<d:createdBy>admin</d:createdBy>
<d:lastModifiedBy>admin</d:lastModifiedBy>
<d:createdDateTime m:type="Edm.DateTimeOffset">2011-03-18T01:39:02Z</
d:createdDateTime>
<d:lastModifiedOn m:type="Edm.DateTime">2011-03-17T21:39:02</d:lastModifiedOn>
<d:lastModifiedDateTime m:type="Edm.DateTimeOffset">2011-03-18T01:39:02Z</
d:lastModifiedDateTime>
</m:properties>
The following Entity Relation Diagram shows the relationship between the different entities. The Person and
Employment objects make up Employee entities. In this diagram, the K fields denote business keys. The field
names here are from the HRIS element.
odata/v2/$metadata
The next diagram shows the relationships for the PerPerson entity. Arrows in the picture denote navigations from
one entity to another. The names written next to the arrows can be used to expand the target entity within an
OData API request. For example:
odata/v2/PerPerson?$filter=personIdExternal+eq+’cgrant1’&$expand=emailNav
This request will return PerPerson entity for cgrant1 and all her emails embedded within the response for
PerPerson entity. For more examples and their responses refer to the section on entities.
Note
The names within << >> provide the name used on the UI while the name next to the +sign denotes a business
key. For example, <<PerAddressDEFLT>> is referred to on the UI as Address Information. It also shows that the
following fields are used as business keys: personIdExternal, startDate, and addressType.
The diagram above shows the major navigations going out of the PerPerson entity while the next diagram shows
the major relationships navigating to the PerPerson entity.
Likewise, the next two diagrams show the navigations from and to the EmpEmployment entity.
The next two diagrams show the navigations from and to the EmpJob entity.
The next diagram shows the relationship for the EmpCompensation entity.
Odata APIs supports navigation for associated entities. For examples of supported scenarios, refer to the section
describing the OData entity.
For EC fields configured as picklists in data model, navigation is available from Employee Central entities to the
Picklist entity.
Employment related entities such as EmpJob, EmpEmployment and EmpCompensation can navigate to the User
entity.
Foundation Object entities can also navigate to the User entity. For example, the manager of the Cost
Center(costcenterManager) in the FOCostCenter entity or the head of the unit(headOfUnit) in the FODivision can
navigate to the User entity. Custom field configured in the Corporate Data Model with Type=Worker can also
navigate to the User entity.
Fields in Employee Central referring to MDF objects such as the Position field in Job Information(EmpJob entity)
can navigate to the position MDF entity. Custom fields configured as MDF type can also navigate to the related
MDF entity.
Note
The navigations described for the Picklist entity, User entity and MDF entity (in the previous sections) are
supported for foundation object navigation as well.
In OData APIs, Employee Central fields related to country can navigate to the Territory Entity. For example,
navigation to the Territory entity exists for the following cases:
● countryOfBirth in PerPerson
● country field in PerNationalIdCard
● FOJobClassLocal
● PerGlobalInfoUSA
Country-specific entities (CSF entities) are defined in the Country Specific Data Model. Examples of such entities
are:
The parent entity can navigate to CSF child entity. For example:
The OData API supports navigation from the CSF entity to the territory entity to get detailed information about the
country.
Some of the CSF parent entities like FOLocation and PerPerson also provide navigation to address information.
For example, FOLocation to FOCorporateAddressDEFLT and PerPerson to PerAddressDEFLT.
Person related entities such as PerPhone, PerEmail can navigate to PerPerson entity; EmpEmployment entity can
navigate to PerPerson entity too.
● PerPersonal
● PerPhone
● PerEmail
● PerNationalId
● PerEmergencyContact
● EmpEmployment
OData APIs support navigation from Employment related entities such as EmpJob, EmpCompensation to the
EmpEmployment entity and vice-versa.
OData APIs support navigation of the User Entity to the EmpEmployment entity.
MDF entities, depending on their configuration, can offer navigation to the User Entity and EC Foundation Objects.
This section describes the different types of Country-Specific(CSF) logic for Employee Central and FO entities.
1.13.1 EmpCompensation/EmpJob/EmpEmployment
The Employee Central CSF configuration allows the use of different labels in the Succession Data Model and the
Country-Specific Succession Data Model for a field however the data type must be the same. For this reason, all
fields from the CSF and the Succession Data Model are merged in the entity and a separate CSF entity does not
exist.
Note
Due to this design, different labels of the country specific entities are not available in the OData metadata yet.
Countries which have not been defined in the Country-Specific Succession Data Model for the HRIS element
globalInfo will not be visible in OData as a PerGlobalInfo<country_code> entity. Because it is not possible to define
the HRIS element globalInfo in the Succession Data Model, there is also no PerGlobal default entity.
For upsert, there is no restriction on the country entity used. For example, the PerGlobalInfoUSA entity can be
used to upsert records for USA, India and Germany.
1.13.3 FOCorporateAddressDEFLT /
HrisEmergencyContactAddressDEFLT
The OData API for these entities offers a single field for all countries. It is not possible to have multiple entities per
country. At the same time, those fields can be defined differently in the Corporate Data Model/Succession Data
Model and the Country-Specific Corporate Data Model/Country-Specific Succession Data Model for attributes
such as visibility, required, picklist, and type.
It is recommended that this flexibility not be used extensively for the following reasons:
● The OData API checks the length for all country-specific configurations and uses the maximum length.
● If a field is configured as a picklist for all countries in the Country-Specific Data Model, the API can expose the
field as a picklist even if different picklists are used. For example, custom_string1 can be defined in the
Country-Specific Corporate Data Model for corporateAddress as picklist=A1, and it can be also defined in
Country-Specific Corporate Data Model for corporateAddress of country=USA as picklist=B1.
● If a field is configured with a different type (Worker / FO / MDF/picklist), the field will be ignored in the ODATA
API query. This applies to the following scenarios:
○ the Succession/Corporate Data Model and the Country Specific Corporate Data Model have different
types, OR
○ the Country Specific Data Model for different countries have different types defined for the same field. For
example, type is defined as a picklist for USA and type is defined as a FO for DEU.
Note: For corporateAddress, the parent entity: FOLocation has a field named: addressId which can uniquely
identify the related corporateAddress field. The same for emergency contact’s address info (addressId).
For FOLegalEntityLocal<country_code>, it is similar, the parent entity FOCompany has three fields: externalCode,
startDdate and country which can uniquely identify the related legal entity local record.
1.13.4 PerAddressDEFLT
The same field can be defined differently in the Succession Data Model and the Country-Specific Data Model for
attributes like visibility, required, picklist, and type.
Note
The information provided in section 7.3 for FOCorporateAddressDEFLT /
HrisEmergencyContactAddressDEFLT apply to PerAddressDEFLT as well.
If there is no country-specific data defined for the HRIS element homeAddress, the definition specified in the
Succession Data Model will be used.
1.13.5 FOLegalEntityLocal<country_code>
The same field can be defined differently in the Succession Data Model and the Country-Specific Data Model for
attributes like visibility, required, picklist, and type. The OData API supports this by providing different entities for
each country (FOLegalEntity<country_code>) and an entity FOLegalEntityDEFLT for all countries that have not
been defined in the Country-Specific Data Model.
For FOLegalEntityLocal<country_code>, the parent entity FOCompany has three fields: externalCode, startDdate
and country which can uniquely identify the related legal entity local record.
1.13.6 FOJobClassLocal<country_code>
For the HRIS element jobClassLocal, the OData API provides the FOJobClassLocal<country_code> entity for each
country defined in the Country-Specific Data model. For all other countries not defined in the Country-Specific
Data model, the FOJobClassLocalDEFLT entity is used.
1.13.7 PerNationalId
Only the format of the HRIS element nationalId can be defined in the Country-Specific Succession Data model.
Other fields for the HRIS element nationalId must be defined in the Succession Data Model.
There is no special handling required for National ID with respect to the OData API query operation.
To understand date handling for Employee Central Entities, you need to understand the concepts of effective
dating, multiple changes per day (MCPD) and last modified query behavior. Please note that when the top level
entity of a query is not effective dated, today's date is used as the asOfDate when the navigation entity is
expanded.
Take a look at the following topics, if these concepts are new to you.
An effective dated entity can have a scheduled data change made to it. Entities can have an effective start date and
an effective end date.
What is it?
When you have an entity that is effective dated, you can track historical data accurately.
The effective date is the date on which the record becomes effective. Effective dating means that records capture
time as part of the data that is stored in SuccessFactors and that the time element can be edited. Effective dating
ensures that you have no time gaps in a record.
Rows for each effective date provide a complete history of the updates to the record. There are no gaps.
When you insert a new record, the end date of the previous record is automatically set to the effective start date -1
day of the next record.
UI Behavior:
When you add a new record to an existing one in an effective dated entity, this is same as making an incremental
upsert using the API with a new key (that is a new date or sequence number)
If you edit an existing record in an effective dated entity, this is same as making an incremental upsert using the
API with the same key (that the same date and sequence number)
For more information on effective dating for each HRIS element, take a look at Employee Central Master
Implementation Guide. Effective dated entities and their behavior [page 36]
Entities with a business key startDate are effective dated. Examples of effective-dated entities include
EmpCompensation,EmpJob, EmpJobRelationships, and PerPersonal.
Note
Please note however that there are a few effective-dated entities that do not have a business key startDate.
● If both the top level entity and the navigation entity of the lower level entities are effective-dated, then when
expanding the navigation entity, the effectiveStartDate of the top level entity is used as the asOfDate of the
navigation entity.
● If the top level entity of the lower level entity is not effective-dated, TODAY is used as the asOfDate when
expanding the navigation entity
● For a Picklist field, the navigation entity is the PicklistValue. When expanding a Picklist field, the
effectiveStartDate/effectiveEndDate of the Picklist entity are used because the PicklistValue itself is not
effective-dated.
The parameters used to query effective dated entities are fromDate, toDate and asOfDate.
Note
If no date is specified and you have the following query
Nice to know
If no date is specified in a query for an effective dated entity - Let's say for example, you have this queryhttps://
<hostname>.com/odata/v2/EmpJob?, then the system applies the asOfDate using today's date, returning the
single record that is valid for all employees on today's date.
You can query effective dated entities using the proprietary parameters:
● asofDate - Querying a specific date (for example asofDate = 01.01.2014 will return the effective dated record
for that day). Always returns a single record.
By default, the OData API uses the asOfDate query using today as the date.
With records that allow multiple changes per day, the record with the highest sequence number is returned.
● fromDate - Querying historic information for a specific date range (for example, from 01.01.2014 to
12.31.2014). Can return more than one record. With records that allow multiple changes per day, the record
with the highest sequence number is returned.
● toDate- Querying historic information for a specific date range (for example, from 01.01.2014 to 12.31.2014).
Can return more than one record. With records that allow multiple changes per day, the record with the
highest sequence number is returned.
Related Information
These proprietary parameters are used to query historical information for a defined time interval for effective
dated entities.
● If you do define a fromDate or a toDate, then the date must be in format YYYY-MM-DD.
● If you do not define a date for fromDate and toDate, then you will get an error.
● You can use the fromDate or toDate alone in query:
These parameters apply to the OData entity named in the request, and to any other entities in the $expand
statement.
Related Information
Here are some examples using the effective dated entity EmpJob in a query – take careful note of the implicit time
intervals.
fromDate
Returns effective dated records in this entity from the date 2000-12-31. The implicit time interval is 2000-12-31 –
system end date.
Depending on the records matching this query, a single record or multiple records can be returned. For entities
that support multiple changes per day, the record with the highest sequence number is returned.
toDate
Depending on the records matching this query, a single record or multiple records can be returned. For entities
that support multiple changes per day, the record with the highest sequence number is returned..
Query: https://<hostname>.com/odata/v2/EmpJob?fromDate=2000-12-31&toDate=2010-12-31
Queries effective dated records in in this entity from 2000-12-31 up to and including 2010-12-31.
Depending on the records matching this query, a single record or multiple records can be returned. For entities
that support multiple changes per day, the record with the highest sequence number is returned.
Consider another example showing the use of the fromDate and toDate:
https://<hostname>.com/odata/v2/PerPersonal?&$filter=startDate+gt
+datetime'2012-10-30T00:00:00'&fromDate=01-01-1990&
$select=startDate,createdOn,personIdExternal&$format=JSON
The example above returns lesser records if the fromDate is not specified. This is because the filter is applied after
the result is already filtered by asOfDate (in this case it would be current date – based on default behavior).
The URI parameters asOfDate, fromDate, toDate are global EC parameters and not standard OData parameters.
This is evident from the naming (they are not preceded by the $ symbol as done for other OData parameters).
They are applied to the OData entity mentioned in the query request, as well as all other expanded entities (those
mentioned within the $expand statement).
Note
If no date is specified and you have the following query
https://<hostname>.com/odata/v2/EmpJob? then the system applies the asOfDate using today’s date.
This returns a single record that is valid for all employees on today’s date
Related Information
Take a look at these examples to see how toDate and/or fromDate combined with $filter behaves.
Query: https://<hostname>.com/odata/v2/EmpJob?$filter=standardHours+gt
+'20'&toDate=2000-12-31
Query: https://<hostname>.com/odata/v2/EmpJob?$filter=standardHours+gt
+'20'&fromDate=2000-12-31
Response returns the effective dated records matching this query. Please note that the implicit time interval is
from 2000-12-31 - system end date.
Query: https://<hostname>.com/odata/v2/EmpJob?$filter=standardHours+gt
+'20'&fromDate=2000-12-31&toDate=2010-12-31
Returns the effective dated records matching this query for the time interval from 2000-12-31 to 2010-12-31.
Related Information
A proprietary parameter used to query effective dated entities valid on the date defined in the query.
If you use an asOfDate and do not define the date, you'll get an error, Unable to parse asOfDate.
You can use either AsOfDate or fromDate/endDate in a query request but not both.
Query: https://<hostname>.com/odata/v2/EmpJob?asOfDate=2000-02-16
Returns the effective dated record that was valid on the given date for all employees. For records that allow
multiple changs per day, the record with the highest sequence number is returned.
Nice to Know
If no date is defined in a query for effective dated entities, then the the asOfDate parameter with today's date is
used. So, assuming that today is 01-01-2020, then this query here:
https://<hostname>.com/odata/v2/EmpJob?&asOfDate=01-01-2020
If both the top level entity and the navigation entity are effective-dated, then when expanding the navigation entity,
the effectiveStartDate of the base entity is used as the asOfDate of the navigation entity.
If you specify fromDate and toDate as query options, then only the top level entity is filtered by the fromDate and
toDate. All lower level entities follow the following rules:
1. If both the top level entity and the navigation entity of the lower level entities are effective-dated, then when
expanding the navigation entity, the effectiveStartDate of the top level entity is used as the asOfDate of the
navigation entity.
2. If the top level entity of the lower level entity is not effective-dated, TODAY is used as the asOfDate when
expanding the navigation entity.
3. For a Picklist field, the navigation entity is the PicklistValue. When expanding a Picklist field, the
effectiveStartDate/effectiveEndDate of the Picklist entity are used because the PicklistValue itself is not effective-
dated.
Response returns the effective dated record valid on the 2000-01-00 for all employees.
Note
If you make the following query:
https://<hostname>.com /odata/v2/EmpJob?$filter=standardHours+gt+'20'
https://<hostname>.com /odata/v2/EmpJob?$filter=standardHours+gt
+'20'&asOfDate=01-01-2020
Related Information
Some entities can be updated multiple times per day. Each update is associated with a sequence number which
provides a history of all changes made to the entity for that day. The entities that allow Multiple Changes Per Day
are:
● EmpJob
● EmpCompensation
● EmpPayComponentsRecurring
To see the MCPD entities in your own instance, look in the metadata to see if an entity has the business key
seqNumber.
● In date range query, all transactions in the table for the specified date range will be returned. Please note that
there might gaps in sequence numbers if records have been deleted.
● In asOfDate query, only the record with the highest transaction sequence number for a specific day of an
employee will be returned.
With MCPD (Multiple Changes Per Day) entities, all records in the time interval are returned when using fromDate
and/or toDate. Depending on the available information for a given time interval, single or multiple records may be
returned. Please note that there might be gaps in the sequence numbering when records have been deleted.
Related Information
When you query an MCPD entity using the asOfDate, the most current record is returned.
Related Information
The fields lastModifiedOn and lastModifiedDateTime store the date and time of the last change or creation in two
different formats: lastModifiedDateTime with datetimeoffset meaning that the query and the response will have
timezone information. lastModifiedOn with datetime meaning that the fields represent the date information in the
timezone of the server (implicit timezone).
When you to create a last modified date query for an effective dated entity, you can use one of the following:
Or
Whether you use lastModifiedDateTime or lastModifiedOn will depend on the time zone information your business
case requires. If you are not familiar with how we treat time zones, please take a look at . [page 21]
Related Information
For the purpose of our examples, we’ll use the parameter lastModifiedDateTime (datetimeoffset) to demonstrate
behavior and usage. Please remember that the behavior and usage of lastModifedOn (datetime) is the same.
When the lastModifiedDate is part of a filter, and at least one record matches the filter criteria, then the response
will contain all effective dated records.
If the effective dated record has been deleted, the data is returned even if there is no existing record with last
modified date (because the record no longer exists). In such a case when the deleted record matches the last
modified date, the response contains the employee with the current record using the asOfDate (=today’s date).
If one effective dated record of an employee matches the filter criteria or was deleted in this timeframe, the
response will contain all effective dated records of the employee.
This behavior can be viewed as standard filter behavior. This is contrast to the behavior of this parameter with
multiple filters.
Related Information
When a lastModifiedDateTime filter is combined with an additional one using AND, the result is a combination of
the filter behavior described in lastModifiedDateTime and $filter [page 44] and the new filter criteria. It is not a
field based filter but a filter which is applied to all records combined with an OR between records. In this case, the
response could well contain a record which only meets one of the $filter criteria and not both.
Example https://<hostname>.com/odata/v2/EmpJob?$filter=lastModifiedDateTime+gt
+datetimeoffset'2016-02-04T12:00:00Z+and+standardHours+eq+'42'
● asOfDate Query: returns information as of a specific date. Always returns a single record. By default, the
OData API uses the asOfDate query using today as the date.
● fromDate and toDate query: returns historic information for the specified date range. Can return multiple
records, depending on information available. For example, if the fromDate is 3/15/2013 and the toDate is
3/30/2013, the returned effective data would be like effective_start_date<=3/30/2013 and
effective_end_date>=3/15/2013. Query request: /jobInfo? fromDate=3/15/2013&toDate=3/30/2013 will
return records from 3/15/2013 to 3/30/2013 for jobInfo entity.
Note
Since the default query is asOfDate, using $filter for effective end or start date will require the fromDate and/or
toDate to be specified. For example, toDate=9999-12-31.
Consider another example showing the use of the fromDate and toDate:
odata/v2/PerPersonal?&$filter=startDate
+gt+datetime'2012-10-30T00:00:00'&fromDate=01-01-1990&
$select=startDate,createdOn,personIdExternal&$format=JSON
The example above returns lesser records if the fromDate is not specified. This is because the filter is applied after
the result is already filtered by asOfDate (in this case it would be current date – based on default behavior).
The URI parameters asOfDate, fromDate, toDate are global EC parameters and not standard OData parameters.
This is evident from the naming (they are not preceded by the $ symbol as done for other OData parameters).
They are applied to the OData entity mentioned in the query request, as well as all other expanded entities (those
mentioned within the $expand statement).
● The date range fromDate / toDate filter can only be applied to the first effective dated entity in a specific
navigation path.
● Date range query only applies to driving entity i.e., the first entity in the navigation path (including the root
entity in the URL which is effective dated).
● The navigation entity will use the asOfDate query by passing the effective start date from the driving entity as
the asOfDate .
Consider the following example where all entities are effective dated:
In this example, specifying the following request will get a data range record from 3/15/2013 to 3/30/2013 for
jobInfo and the related department records with asOfDate = effective start day of the joined jobInfo record.
odata/v2/jobInfo?
fromDate=3/15/2013&toDate=3/30/2013&$expand=departmentNav
In case there are several effective dated objects in the navigation path, for example Job Information navigates to
Department and Department navigates to CostCenter, the request would be:
odata/v2/jobInfo?
fromDate=3/15/2013&toDate=3/30/2013&$expand= departmentNav,
departmentNav/costCenterNav
This will return all corresponding effective dated records for Job Information. For each record, a single department
(as in the image above) will be returned. The same is true for the expanded Cost Center. Each department will have
a single cost center record depending on the effective start date of the parent entity.
For asOfDate query requests, the asOfDate parameter will be applied to all effective dated objects in the same
query including the driving entity and the expanded entity. For example, specifying the following request will get a
snapshot of the record that has asOfDate=3/30/2013 for jobInfo and the related department records with
asOfDate= 3/30/3013.
odata/v2/jobInfo?asOfDate=3/30/2013&$expand=departmentNav
For date range query, if the navigation is from an effective-dated entity to a non-effective dated entity to an
effective-dated entity, the second effective-dated entity will use the asOfDate query.
odata/v2/EmpJob?$filter=jobCode
odata/v2/EmpJob?$filter=jobCode +eq+
'ENG'&$expand=employmentNav&$select=startDate,jobCode&$format=JSON
The above example queries all developers based on job code (ENG) in the system and returns the hire
date(startDate).
When the first entity in the navigation path is non-effective dated, the first effective dated entity in the navigation
path applies to the date range query criteria. Likewise, the asOfDate parameter can be passed to effective dated
entities within the navigation path of the non-effective dated root entity.
Example 1: This request returns the non-effective dated employmentInfo record and applies the
asOfDate=3/15/2013 query to the expanded jobInfo entity only.
odata/v2/EmpEmployment?asOfDate=3/15/2013&$expand=jobInfoNav
Example 2: This request returns the non-effective dated employmentInfo record and applies the asOfDate query
using the current date to the expanded jobInfo entity only
Example 3: This request returns the non-effective dated employmentInfo record and applies the date range query
using fromDate=3/15/2013&toDate=3/30/2013 to the expanded jobInfo entity only.
odata/v2/EmpEmployment?fromDate=3/15/2013&toDate=3/30/2013&$expand=
jobInfoNav
Employee Central Entities allow you to create and manipulate employee data. Navigations in an entity represent
associations between entities. Each entity can have the following properties.
● Effective dating
● Business keys
● Required/nullable attribute
● Processing parameters for upsert
If you need to retrieve changed records, then you will be wanting to use the lastmodifeddate in your query.
Business Case
You might need to retrieve changes to records when you are synchronizing systems using APIs, for example from
a SF instance to a client local database.
How do I do that?
You can use a last modified query. Take a look at the example below
If you need to retrieve changes to records, then you will be wanting to use last modified query. For example if you
want to sync EmpJob
Table 11:
Operation GET
URI http://<Hostname>/odata/v2/EmpJob?
fromDate=01-01-1900&
$filter=lastModifiedDateTime+gt
+datetimeoffset'2016-02-01T12:40:03Z'
Sample Code
Extract from response to the above query focussing on the last modified information. Take note that the query
is for records changed after 2016-02-01T12:40:03Z but that the request has returned last modified information
that predates this.
<m:properties>
<d:startDate m:type="Edm.DateTime">2015-08-01T00:00:00</d:startDate>
<d:userId>215</d:userId>
.....
<d:lastModifiedDateTime m:type="Edm.DateTimeOffset">2015-08-13T14:01:06Z</
d:lastModifiedDateTime>
.....
<d:lastModifiedOn m:type="Edm.DateTime">2015-08-13T10:01:06</d:lastModifiedOn>
....
</m:properties>
Business keys are a set of fields that uniquely identity a record for an entity. Each entity, at minimum, uses the
following fields to make up a business key:
An individual entity can have additional fields that make up its business key. Fields that make up business keys are
required fields and cannot be marked as nullable for all entities. A list of business keys for Employee Central
objects is shown below:
Table 13:
Entity Business Keys Business key in Imports Special Keys
FOFrequency external_code
FOWfConfig external_code
FODynamicRole external_code
Note
It is important that the business keys be unique. It is recommended that business keys in data models be
defined as required=true. In case, duplicate records are found, only one record will be returned and others
ignored.
By default, the nullable attribute is set to false (nullable=false) for business keys. All other fields have this
property set to true.
The required attribute is determined by the data model. For business keys, this is always set to true. This is
different from the EC SFAPI behavior.
The Employee Central Upsert API supports both Full purge and Incremental updates using parameters. If no
parameters are provided, the system checks whether the entity being updated supports incremental update. If it
does, an incremental update is performed. Else, the system performs a full purge on the record.
If the processing parameter is set to full purge, the existing record for the given employee is deleted when the
upsert operation is performed. A new record is then created with the data specified in the payload. In SOAP, the
purgeType is specified as follows:
<urn:processingParam>
<urn:name>purgeType</urn:name>
<urn:value>FULL</urn:value>
</urn:processingParam>
In OData, the purgeType is specified through a URL parameter. A typical request would look like:
odata/v2/upsert?purgeType=full
1.17.5.2 Incremental
If the processing parameter for an upsert is set to Incremental, only records specific to the user in the payload are
purged and replaced. This means all other records for the user remain untouched.
<urn:processingParam>
<urn:name>purgeType</urn:name>
<urn:value>INCREMENTAL</urn:value>
</urn:processingParam>
In OData, the purgeType is specified through a URL parameter. A typical request would look like:
odata/v2/upsert?purgeType=incremental
For incremental load, if an entity supports NO_OVERWRITE then the fields that do not appear in the Upsert
request are not overwritten. For some entities, some fields might support NO_OVERWRITE while others do not.
For example, for the PerEmergencyContacts entity, name and relationship do not support NO_OVERWRITE, but
address information supports NO_OVERWRITE.
Note
To determine if the entity supports NO_OVERWRITE, refer to the section on HRIS Element Information for the
specific entity.
1.17.6 suppressUpdateOfIdenticalData
Many a times, during replication, the source system does not have information about changes to a field or entity
level. As a result, more than necessary data is transferred; in some cases, a full replication is triggered from the
third-party system into Employee Central. This results in an update of records in Employee Central even if those
records are not changed. If other integration transferring data out of Employee Central are based on the audit
information in Employee Central they will always get data even if there was no change.
OData supports a mode called suppressUpdateOfIdenticalData which can be enabled to ensure that records are
updated only if needed. This means that data will not be updated by imports/OData API calls if there is no change
i.e. if the payload and the data in the system is the same. In such a case, there is no update to last_modified dates,
no creation of audit information and no change to entity data.
It is available in full purge and incremental mode for the following entities:
● PerPerson
● PerPersonal
● EmpEmployment
● EmpJobInformation
A typical request with the suppressUpdateOfIdenticalData parameter would look like this:
http://<hostname>/odata/v2/upsert?purgeType=full&suppressUpdateOfIdenticalData=true
1.17.7 fileLocale
What is it?
A new url parameter, fileLocale, is now available for upserts. en_US is currenty supported so in other words, like
the UI and the import engine, OData APIs now support the internationalization of floating decimal points.
You’ll be able to avoid roundtrip inconsistencies that arise when your API user locale is not en_US. Up to now, you
could only address this problem by changing the user locale which in many cases is impractical.
When you|re replicating data from 3rd party systems, the EC system by default will always read data as if the
locale is en_US. This is not problematic if the API user locale is also en_US and the upserted data uses US decimal
notation.
If however, your API user locale is not en_US and is for example de_DE, you’d end up with roundtrip
inconsistencies. This is because when an application reads data in a productive system using an OData API query
and subsequently copies it into another system using an upsert statement, the number fields are rendered in the
locale of the API user and in the case of user locale = de_DE, you'll end up with inconsistencies because en_US and
de_DE use a different decimal notation.. fileLocale=en_US will solve this problem.
Good to know
If you API users locale is en_US, you will not need to use fileLocale=en_US.
Add fileLocale=en_US to your upsert queries when your user locale is not en_US.
Your API user locale is de_DE. So, when upserting, make sure to use the following:
Query: https://<hostname>.com/odata/v2/upsert?fileLocale=en_US
Payload:
Sample Code
{
"__metadata": { "uri":"EmpEmployment" },
"personIdExternal": "aaaa",
"userId": "aaaa", "InitialOptionGrant": "224.8",
"InitialStockGrant": "31,000"
}
To get the most out of this guide, you will also need the following to hand:
This guide lists the required fields for the entities and sample code. The other fields, navigation properties and so
on are available in the OData API dictionary and metadata. You need to refer to these sources of information to get
a complete picture of the entities properties and capabilities
The OData API dictionary contains all the entities available in your instance, it lists the allowed operations, the field
(property name), the label as well as telling you which fields are required or not. To view the OData dictionary, you:
1. Navigate to the Admin Center and select Company Settings OData API Data Dictionary .
2. The OData API Data Dictionary is displayed. This can take a while. Once the page loads, scroll to the entity in
question. For this example, let's expand PerPhone.
In order to get extra information, such as language labels, picklists, beyond what the standard OData metadata
provides, Successfactors OData exposes metadata as an entity
The following API call allows you the access the entire metadata for your instance:
https://api4.successfactors.com/odata/v2/$metadata
The following API call shows you how to access the metadata for only the User entity:
https://<hostname>/odata/v2/Entity('User')?$format=json
The following API call shows you how to access the metadata for the User and Photo entities:
https://api4.successfactors.com/odata/v2/User,Photo/$metadata
You can use the same URL to query User entity data:
https://api4.successfactors.com/odata/v2/User,Photo/User?$format=json&$filter=userId eq
‘cgrant’
In addition to the information you can get from the OData API dictionary about an entity, the metadata will give you
information on the entities associated with the entity, picklists, relationships between the entity and other entities
and so on. To call up the metadata, use this query. Please note that this is can take a while as it downloads
metadata for all entities.:
https://<hostname>/odata/v2/$metadata
2.1 AdvancesAccumulation
This entity records the accumulation of the requested advance and remaining eligibility for the user . It is not a
effective dated entity in the Advances module. This entity is created when a advance is approved by the
superviser.
Permissions
Table 14:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions for AdvancesAccumulation.
● Enable Advances
● Enable Generic Objects
● Enable Deductions Management
● Effective Dated Data Platform
● Enable the Attachment Manager
Operations Allowed
Table 15:
Operation Description
Table 16:
Property Description
Navigation Properties
Table 17:
Navigation Property Related Entity Description
Use Cases
Table 18:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('AdvancesAccumulation')", "type" : "SFOData.Entity"
}, "path" : "AdvancesAccumulation", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : 128, "name" : "externalCode",
"path" : "AdvancesAccumulation/externalCode", "picklistOptionId" : null,
"required" : true, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
2.2 AdvancesEligibility
This entity is used to configure different advances that a company offers to its employees. It is also used to
configure the recovery of the advance.
Permissions
Table 19:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Admin Manage Advances Advances
Eligibility .
● Enable Advances
● Enable Generic Objects
● Enable Deductions Management
● Effective Dated Data Platform
● Enable the Attachment Manager
Table 20:
Operation Description
Properties
Table 21:
Property Description
Navigation Properties
None.
Use Cases
Table 22:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('AdvancesEligibility')", "type" : "SFOData.Entity"
}, "path" : "AdvancesEligibility", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
2.3 NonRecurringPayment
Table 23:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions for NonRecurringPayment.
● Enable Advances
● Enable Generic Objects
● Enable Deductions Management
● Effective Dated Data Platform
● Enable the Attachment Manager
Operations Allowed
Table 24:
Operation Description
Properties
Table 25:
Property Description
Table 26:
Navigation Property Related Entity Description
Use Cases
Table 27:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('NonRecurringPayment')", "type" : "SFOData.Entity"
}, "path" : "NonRecurringPayment", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : 128, "name" : "externalCode",
"path" : "NonRecurringPayment/externalCode", "picklistOptionId" : null,
"required" : false, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}
]
}, "upsertable" : true, "name" : "NonRecurringPayment", "updatable" : true,
"deletable" : true, "properties" : {
"results" : [
{
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "advance",
"path" : "NonRecurringPayment/advance", "picklistOptionId" : null, "required" :
false, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : false, "label" : null, "maxLength" : 255, "name" : "createdBy",
"path" : "NonRecurringPayment/createdBy", "picklistOptionId" : null, "required" :
false, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : false, "upsertable" : false, "viewable" : true
}, {
3.1 Apprentice
This entity provides a single and simple way of accessing the content from the Apprentice.
Permissions
Operations Allowed
Table 28:
Operation Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
3.2 ApprenticeEventType
This entity provides a single and simple way of accessing the content from the Apprentice Event Type.
Permissions
Operations Allowed
Table 29:
Operation Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
This entity provides a single and simple way of accessing the content from the Apprentice Internal Training Event.
Permissions
Access to the Apprentice Internal Training Event object is regulated by role-based permissions.
Operations Allowed
Table 30:
Operation Description
Code Examples
Code Example:
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://mo-e40605f30.mo.sap.corp:443/odata/v2/
ApprenticeInternalTrainingEvent(6723L)",
"type": "SFOData.ApprenticeInternalTrainingEvent"
},
This entity provides a single and simple way of accessing the content from the Apprentice Practical Training Event.
Permissions
Access to the Apprentice Practical Training Event object is regulated by role-based permissions.
Operations Allowed
Table 31:
Operation Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://mo-e40605f30.mo.sap.corp:443/odata/v2/
ApprenticePracticalTrainingEvent(6967L)",
"type": "SFOData.ApprenticePracticalTrainingEvent"
},
"externalCode": "6967",
"startDateAndTime": "/Date(1453158000000+0000)/",
"mdfSystemEffectiveEndDate": "/Date(253402214400000)/",
"mdfSystemObjectType": "ApprenticePracticalTrainingEvent",
"mdfSystemVersionId": null,
This entity provides a single and simple way of accessing the content from the Apprentice School.
Permissions
Operations Allowed
Table 32:
Operation Description
3.6 ApprenticeSchoolEvent
This entity provides a single and simple way of accessing the content from the Apprentice School Event.
Permissions
Table 33:
Operation Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://mo-e40605f30.mo.sap.corp:443/odata/v2/
ApprenticeSchoolEvent(6822L)",
"type": "SFOData.ApprenticeSchoolEvent"
},
"externalCode": "6822",
"startDateAndTime": "/Date(1448838000000+0000)/",
"mdfSystemEffectiveEndDate": "/Date(253402214400000)/",
"mdfSystemObjectType": "ApprenticeSchoolEvent",
"mdfSystemVersionId": null,
"shareStatus": "NOT_SHARED",
"eventType": "6604",
"lastModifiedDateTime": "/Date(1448889138000+0000)/",
"mdfSystemTransactionSequence": "1",
"mdfSystemRecordId": "90D6E02E7CE0445299AD625C5E9A1CA7",
"mdfSystemEntityId": "04213BA663004D05AECED2E6E80CDD69",
"mdfSystemStatus": "A",
"lastModifiedDateWithTZ": "/Date(1448889138000+0000)/",
"createdDate": "/Date(1448888089000)/",
"note": null,
"mdfSystemRecordStatus": "N",
"isAllDayEvent": true,
"school": null,
"endDateAndTime": "/Date(1449269999000+0000)/",
"createdBy": "admin",
"lastModifiedBy": "admin",
"createdDateTime": "/Date(1448888089000+0000)/",
"lastModifiedDate": "/Date(1448889138000)/",
"mdfSystemEffectiveStartDate": "/Date(-2208988800000)/",
"eventName": "School",
"schoolNav": {
4.1 VendorInfo
Operations Allowed
Table 34:
Operation Description
Properties
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Use Cases
Operation Get
URI https://host.com/odata/v2/VendorInfo?
$format=json&$top=1
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://host.com/odata/v2/
VendorInfo(effectiveStartDate=datetime'1992-07-01T00:00:00',vendorCode='Wipro')",
"type": "SFOData.VendorInfo"
},
"vendorCode": "Wipro",
"effectiveStartDate": "\/Date(709948800000)\/",
"mdfSystemLastModifiedDate": "\/Date(1469138991000)\/",
"mdfSystemObjectType": "VendorInfo",
"mdfSystemLastModifiedDateWithTZ": "\/Date(1469138991000+0000)\/",
"description_ro_RO": null,
"lastModifiedDateTime": "\/Date(1469138991000+0000)\/",
"description_fr_CA": null,
"effectiveStatus": "A",
"mdfSystemRecordId": "820AB0FD94394715B790117136881365",
"mdfSystemEntityId": "95C37BBA405341EEB1E13D5635CD23D6",
"description_cs_CZ": null,
"description_de_DE_SF": null,
"description_fi_FI": null,
"description_de_CH": null,
"mdfSystemLastModifiedBy": "WF1",
"description_bg_BG": null,
"description_nb_NO": null,
"description_fr_FR_SF": null,
"mdfSystemRecordStatus": "N",
"description_ko_KR": null,
"description_sv_SE": null,
"description_en_US": null,
"description_bs_BS_SF": null,
"description_es_MX": null,
"description_pt_PT": null,
"mdfSystemCreatedDate": "\/Date(1469138991000)\/",
"description_hu_HU": null,
"description_zh_TW_SF": null,
"description_es_ES_SF": null,
"createdBy": "WF1",
"description_pt_BR": null,
"description_en_GB_SF": null,
"description_ja_JP": null,
"description_zh_CN_SF": null,
"lastModifiedBy": "WF1",
"createdDateTime": "\/Date(1469138991000+0000)\/",
"description_hr_HR": null,
"description_defaultValue": null,
"description_hi_IN": null,
"mdfSystemEffectiveEndDate": "\/Date(253402214400000)\/",
"description_da_DK": null,
"mdfSystemVersionId": null,
"description_uk_UA": null,
"description_it_IT_SF": null,
"description_sl_SI": null,
"description_vi_VN": null,
"mdfSystemTransactionSequence": "1",
"description_tr_TR": null,
"description_bs_ID": null,
"description_th_TH": null,
"description_cy_GB": null,
"description_sr_RS": null,
"description_localized": null,
4.2 WorkOrder
Permissions
Table 37:
Operation Description
Properties
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Use Cases
Operation Get
URI http://<Hostname>/odata/v2/WorkOrder?
$format=json$top=1
Response
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://hostname.com:443/odata/v2/
WorkOrder(effectiveStartDate=datetime'2016-07-01T00:00:00',userSysId='ffff')",
"type": "SFOData.WorkOrder"
},
"effectiveStartDate": "\/Date(1467331200000)\/",
"userSysId": "ffff",
"startDate": "\/Date(1467331200000)\/",
"mdfSystemObjectType": "WorkOrder",
"mdfSystemVersionId": null,
"endDate": "\/Date(1469923200000)\/",
"effectiveStatus": "A",
"lastModifiedDateTime": "\/Date(1469139083000+0000)\/",
5.1 DeductionScreenId
This entity provides the screen IDs that are required for configuring the Deduction UI in Employee Central.
Permissions
Table 39:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions for DeductionScreenId.
Operations Allowed
Table 40:
Operation Description
Properties
Table 41:
Property Description
Table 42:
Navigation Properties Related Entity Description
Use Cases
Table 43:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('DeductionScreenId')", "type" : "SFOData.Entity"
}, "path" : "DeductionScreenId", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : 128, "name" : "externalCode",
"path" : "DeductionScreenId/externalCode", "picklistOptionId" : null, "required" :
false, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}
]
}, "upsertable" : true, "name" : "DeductionScreenId", "updatable" : true,
"deletable" : true, "properties" : {
"results" : [
{
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : false, "label" : null, "maxLength" : 255, "name" :
"dummyFieldValue", "path" : "DeductionScreenId/dummyFieldValue",
"picklistOptionId" : null, "required" : false, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : false, "upsertable" : false, "viewable" : true
}, {
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : 128, "name" : "externalCode",
"path" : "DeductionScreenId/externalCode", "picklistOptionId" : null, "required" :
false, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : false, "label" : null, "maxLength" : 255, "name" :
5.2 OneTimeDeduction
Permissions
Table 44:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Manage Deductions . Assign the relevant
permissions for deductions.
Table 45:
Operation Description
Properties
Table 46:
Property Description
Navigation Properties
Table 47:
Navigation Property Related Entity Description
Use Cases
Table 48:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('OneTimeDeduction')", "type" : "SFOData.Entity"
}, "path" : "OneTimeDeduction", "insertable" : true, "keyProperties" : {
5.3 RecurringDeduction
An entity used for subtracting expenses from the gross income of employees.
Table 49:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions for RecurringDeductions.
Operations Allowed
Table 50:
Operation Description
Properties
Table 51:
Property Description
Navigation Properties
Table 52:
Navigation Property Related Entity Description
Use Cases
Table 53:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('RecurringDeduction')", "type" : "SFOData.Entity"
}, "path" : "RecurringDeduction", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"effectiveStartDate", "path" : "RecurringDeduction/effectiveStartDate",
"picklistOptionId" : null, "required" : true, "sortable" : true, "type" : {
"name" : "datetime", "path" : "datetime"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : 128, "name" : "userSysId",
"path" : "RecurringDeduction/userSysId", "picklistOptionId" : null, "required" :
true, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}
]
}, "upsertable" : true, "name" : "RecurringDeduction", "updatable" : true,
"deletable" : true, "properties" : {
"results" : [
{
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : false, "label" : null, "maxLength" : null, "name" :
"effectiveEndDate", "path" : "RecurringDeduction/effectiveEndDate",
"picklistOptionId" : null, "required" : false, "sortable" : true, "type" : {
"name" : "datetime", "path" : "datetime"
}, "updateable" : false, "upsertable" : false, "viewable" : true
}, {
6.1 EmpBeneficiary
Operations Allowed
Table 54:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
In Provisioning the following feature has to be enabled to make this entity visibile: "Enable Pension Payouts"
Properties
Table 55:
Property Description
plannedEndDate
payrollEndDate The last payroll for this employee. By default, this is the same date as the termina
tion date, unless you change it here.
lastModifiedBy The ID of the person who made the lastest updated to the entry
Navigation Properties
Table 56:
Navigation Property Related Entity Description
Related Information
6.2 EmpCompensation
Table 57:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 58:
Property Description
payGrade
payGroup Pay group of the employee. If you have defined pay group
foundation objects, this field contains the external code of
those pay groups.
notes A text field where the user can enter additional information if
required.
benefitsRate
payrollSystemId The ID of the payroll system used for compensating the em
ployee.
eventReason If you have defined event reason foundation objects, this field
contains the external code of those event reasons.
event
budgetGroup
isInsider Used to track insider trading on the stock market. You can de
fine if an employee has access to insider information and is
thus considered an insider according to the local insider law,
for example, the Securities Exchange Act in the USA.
pensionableSalary
lastModifiedBy The ID of the person who made the lastest updated to the
compensation entry
When you make a last modified query, take a look at how this entitiy behaves with $filter and lastModifiedOn:
Table 59:
Use Cases
Table 60:
API Call Description
https://<hostname>/odata/v2/ Get all Persons which are in pay group 'xxx' and are created af
EmpCompensation?$filter=payGroup eq ter 'xxxx-xx-xx'
'NA_GROUP' and createdOn gt
datetime'2011-08-01T00:00:00'&$format=JSON
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpCompensation(seqNumber=1L,startDate=datetime'2011-08-15T00:00:00',userId='rallen1
')",
"type": "SFOData.EmpCompensation"
},
"startDate": "/Date(1313366400000)/",
"userId": "rallen1",
"seqNumber": "1",
"endDate": "/Date(253402300799000)/",
"isEligibleForCar": false,
"lastModifiedDateTime": "/Date(1325617370000+0000)/",
"benefitsRate": "0",
"event": "2294",
"payGrade": null,
Related Information
6.2.1 empCompensationCalculated
This entity exposes a transient value that you see in the Compensation Information portlet.
Tell Me More
● GetCompaRatioByUserDateAndSeq - This calculates the Compa-Ratio field that you see in the Compensation
Information portlet.
● GetRangePenetrationByUserDateAndSeq - This calculates the Range Penetration field that you see on the
Compensation Information portlet.
Neither Compa-Ratio nor Range Penetration is stored on the database so both fields are treated as transient
fields. If you want to expose their values, you need to use empCompensationCalculated.
It has been designed for use in UI scenarios and is not suitable for mass data replication.
Operations Allowed
Transient values are not stored to the database so you can't query them directly. Instead you have to treat
empCompensationCalculated as a child entity of EmpCompensation. In addition to $expand, you can also use the
operators $select and $format with the GET operation but please note that $filter,$orderby, $skip, and $top are
not supported.
Properties
Make sure to check the entity properties in your OData API Dictionary as the entity in your particular instance may
differ slightly from the description here.
errorCode The errorCode "Success" indicates that the call has been suc
cessful and calculation results are returned.
errorMessage The errorCode "ErrorMximumRecord" indicates that the num
ber of records called exceeds the maximum of 50 and the calls
will not be made.
Use Cases
Table 62:
API Call Description
Code Examples
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
EmpCompensation(seqNumber=1L,startDate=datetime'2008-07-01T00:00:00',userId='pluca
s1')",
"type": "SFOData.EmpCompensation"
},
"startDate": "/Date(1214870400000)/",
"userId": "plucas1",
"seqNumber": "1",
"endDate": "/Date(253402214400000)/",
"isEligibleForCar": null,
"lastModifiedDateTime": "/Date(1263496137000+0000)/",
"benefitsRate": null,
Related Information
6.2.2 empCompensationGroupSumCalculated
This entity exposes a transient value that is calculated from the pay component group sums that are in the
compensation information record
Tell Me More
It has been designed for use in UI scenarios and is not suitable for mass data replication.
Transient values are not stored to the database so you can't query them directly. Instead you have to treat
empCompensationGroupSumCalculated as a child entity of EmpCompensation. In addition to $expand, you can
also use the operators $select and $format with the GET operation but please note that $filter,$orderby, $skip,
and $top are not supported.
Properties
Make sure to check the entity properties in your OData API Dictionary as the entity in your particular instance may
differ slightly from the description here.
Table 63:
errorCode The errorCode "Success" indicates that the call has been suc
cessful and calculation results are returned.
errorMessage The errorCode "ErrorMximumRecord" indicates that the num
ber of records called exceeds the maximum of 50 and the calls
will not be made.
Use Cases
Table 64:
API Call Description
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
EmpCompensation(seqNumber=1L,startDate=datetime'2008-07-01T00:00:00',userId='pluca
s1')",
"type": "SFOData.EmpCompensation"
},
"startDate": "/Date(1214870400000)/",
"userId": "plucas1",
"seqNumber": "1",
"endDate": "/Date(253402214400000)/",
"isEligibleForCar": null,
"lastModifiedDateTime": "/Date(1263496137000+0000)/",
"benefitsRate": null,
"event": null,
"isHighlyCompensatedEmployee": null,
"eventReason": null,
"payGroup": null,
"lastModifiedOn": "/Date(1263496137000)/",
"createdOn": "/Date(1263496137000)/",
"createdBy": "admin",
"createdDateTime": "/Date(1263496137000+0000)/",
"lastModifiedBy": "admin",
"payType": "1597",
"notes": null,
"isEligibleForBenefits": null,
...
}
},
"empCompensationGroupSumCalculatedNav": {
"results": []
}
}
]
}
Related Information
Operations Allowed
Table 65:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 66:
Property Description
originalStartDate If the employee has been working for the company before, en
ter the date of the first hire in the organization in this field.
isPrimary
lastDateWorked The last day the employee worked for the company. By de
fault, this is the same date as the termination date, unless you
change it here.
regretTermination If this termination is a loss for the organization, set this field to
Yes.
eligibleForSalContinuation This field indicates that the employee is eligible for salary con
tinuation. Possible values are Yes and No.
salaryEndDate Salary is paid until this date. By default, this is the same date
as the termination date, unless you change it here.
StockEndDate Stocks are granted until this date. By default, this is the same
date as the termination date, unless you change it here.
benefitsEndDate Benefits are granted until this date. By default, this is the same
date as the termination date, unless you change it here.
serviceDate
professionalServiceDate
jobCredit
notes Text field where the user can enter additional information if re
quired.
firstDateWorked Enter the first date of the employee's working contract with
the company.
assignmentClass
lastDateWorked The last day the employee worked for the company. By de
fault, this is the same date as the termination date, unless you
change it here.
Table 67:
Navigation Property Related Entity Description
Use Cases
Table 68:
API Call Description
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
EmpEmployment(personIdExternal='mcolton1',userId='184')",
"type": "SFOData.EmpEmployment"
},
"personIdExternal": "mcolton1",
"userId": "184",
"startDate": "/Date(1420070400000)/",
"eligibleForStock": null,
"initialOptionGrant": null,
"payrollEndDate": null,
"serviceDate": null,
"professionalServiceDate": null,
"okToRehire": null,
"regretTermination": null,
"endDate": null,
"eligibleForSalContinuation": null,
"lastModifiedDateTime": "/Date(1418718010000+0000)/",
"StockEndDate": null,
"assignmentClass": "GA",
"lastDateWorked": null,
"salaryEndDate": null,
"originalStartDate": null,
"benefitsEndDate": null,
"lastModifiedOn": "/Date(1418700010000)/",
"initialStockGrant": null,
"bonusPayExpirationDate": null,
"createdOn": "/Date(1418700010000)/",
"createdBy": "admin",
"createdDateTime": "/Date(1418718010000+0000)/",
"lastModifiedBy": "admin",
"customString1": null,
"seniorityDate": null,
"empPayCompNonRecurringNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/
EmpEmployment(personIdExternal='mcolton1',userId='184')/empPayCompNonRecurringNav"
}
},
"compInfoNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/
EmpEmployment(personIdExternal='mcolton1',userId='184')/compInfoNav"
}
},
"personNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/
EmpEmployment(personIdExternal='mcolton1',userId='184')/personNav"
}
},
"jobInfoNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/
EmpEmployment(personIdExternal='mcolton1',userId='184')/jobInfoNav"
}
},
"wfRequestNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/
EmpEmployment(personIdExternal='mcolton1',userId='184')/wfRequestNav"
6.4 EmpEmploymentTermination
This entity contains employment or global assignment termination information for an employee.
Operations Allowed
Table 69:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 70:
Property Description
regretTermination If this termination is a loss for the organization, set this field to
Yes.
bonusPayExpirationDate Bonus pays are being paid until this date. By default, this is the
same date as the termination date, unless you change it here.
eligibleForSalContinuation This field indicates that the employee is eligible for salary con
tinuation. Possible values are Yes and No.
salaryEndDate Salary is paid until this date. By default, this is the same date
as the termination date, unless you change it here.
StockEndDate Stocks are granted until this date. By default, this is the same
date as the termination date, unless you change it here.
notes This is a text field where the user can enter additional informa
tion if required.
lastModifiedBy The ID of the person who made the lastest updated to the ter
mination entry
Table 71:
Navigation Property Related Entity Description
Use Cases
Table 72:
API Call Description
Code Examples
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://salesdemo4.successfactors.com:443/odata/v2/
EmpEmploymentTermination(endDate=datetime'2014-12-09T00:00:00',personIdExternal='hmu
eller1',userId='189')", "type" : "SFOData.EmpEmploymentTermination"
}, "personIdExternal" : "hmueller1", "userId" : "189", "endDate" : "\/
Date(1418083200000)\/", "payrollEndDate" : null, "benefitsEndDate" : null,
"okToRehire" : null, "regretTermination" : null, "eligibleForSalContinuation" :
null, "lastModifiedDateTime" : "\/Date(1418732822000+0000)\/", "lastModifiedOn" :
"\/Date(1418714822000)\/", "bonusPayExpirationDate" : null, "StockEndDate" : null,
"createdOn" : "\/Date(1418709564000)\/", "createdBy" : "admin", "createdDateTime" :
"\/Date(1418727564000+0000)\/", "lastDateWorked" : null, "lastModifiedBy" :
"admin", "salaryEndDate" : null, "notes" : null, "personNav" : {
"__deferred" : {
"uri" : "https://salesdemo4.successfactors.com:443/odata/v2/
EmpEmploymentTermination(endDate=datetime'2014-12-09T00:00:00',personIdExternal='hmu
eller1',userId='189')/personNav"
}
}, "userNav" : {
This entity contains details about the global assignment for an employee. A new Global Assignment can be created
or updated using an upsert call for EmpGlobalAssignment. In such a case a new assignment of type gobal
assignment can be created. This means there can be a new record in EmpGlobalAssignment and a new entry in the
User entity for this person. Since EmpGlobalAssignment and EmpEmployment share the same persistency each
Global Assignment appears as an Employment in EmpEmployment with type global assignment.
Operations Allowed
Operation Description
Properties
Table 74:
Property Description
assignmentType The type of the global assignment. The list of values comes
from the picklist global_assignment_type.
assignmentClass
createdOn The date that the global assignment information was added.
lastModifiedBy The ID of the person who made the lastest updated to the
global assignment entry
Navigation Properties
Table 75:
Navigation Property Related Entity Description
Table 76:
API Call Description
Code Examples
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://<hostname>.com:443/odata/v2/EmpGlobalAssignment('183')", "type" :
"SFOData.EmpGlobalAssignment"
}, "userId" : "183", "startDate" : "\/Date(1417392000000)\/", "payrollEndDate" :
null, "endDate" : null, "lastModifiedDateTime" : "\/Date(1415696549000+0000)\/",
"lastModifiedOn" : "\/Date(1415678549000)\/", "createdOn" : "\/
Date(1415678549000)\/", "assignmentClass" : "GA", "personIdExternal" : "ttest",
"createdBy" : "admin", "assignmentType" : "6131", "plannedEndDate" : "\/
Date(1446336000000)\/", "createdDateTime" : "\/Date(1415696549000+0000)\/",
"lastModifiedBy" : "admin", "customString1" : null, "customString110" : null,
"userNav" : {
"__deferred" : {
"uri" : "https://<hostname>.com:443/odata/v2/EmpGlobalAssignment('183')/userNav"
}
}, "assignmentTypeNav" : {
"__deferred" : {
"uri" : "https://<hostname>.com:443/odata/v2/EmpGlobalAssignment('183')/
assignmentTypeNav"
}
}, "employmentNav" : {
"__deferred" : {
"uri" : "https://<hostname>.com:443/odata/v2/EmpGlobalAssignment('183')/
employmentNav"
}
}
}
]
}
}
In Provisioning the following feature has to be enabled to make this entity visible: "Enable Global Assignment
Management"
6.6 EmpJob
This entity contains information about the job associated with an employee.
Operations Allowed
Operation Description
Business Fields
● seqNumber
● startDate
● userID
● businessUnit
● company
● eventReason
● jobCode
● startDate
● userId
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
When you use a picklist label (picklistLabels) in a $filter query, specify the locale to avoid duplicate records.
Background: When a picklist has more than one locale and this is not defined in a query, all the locales will be
queried. This could result in duplicate records.
$filter=<entity>Nav/picklistLabels/locale eq 'en_US'
lastmodifiedquery
When you make a last modified query, take a look at how this entity behaves with $filter and lastModifiedOn:
Table 78:
API Call Description
https://<hostname>/odata/v2/EmpJob? Get all Persons having Carla Grant as Manager and working for
$filter=company eq 'ACE_USA' and managerId ACE_USA
eq 'cgrant1'&$select=employmentNav/
personNav/personalInfoNav/
firstName,employmentNav/personNav/
personalInfoNav/lastName,company&
$format=JSON
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpJob(seqNumber=1L,startDate=datetime'2010-12-01T00:00:00',userId='rallen1')",
"type": "SFOData.EmpJob"
},
"company": "ACE_USA",
"employmentNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpJob(seqNumber=1L,startDate=datetime'2010-12-01T00:00:00',userId='rallen1')/
employmentNav"
}
}
}
]
}
}
Related Information
6.7 EmpJobRelationships
This entity contains the employee relationship information to one or more managers.
Operation Description
Properties
Table 80:
Property Description
operation
createdOn The date that the job relationship information was added.
lastModifiedBy The ID of the person who made the lastest updated to the job relationship informa
tion.
When you make a last modified query, take a look at how this entitiy behaves with $filter and lastModifiedOn:
Navigation Properties
Table 81:
Navigation Property Related Entity Description
Use Cases
Table 82:
API Call Description
https://<hostname>.com/odata/v2/ Get all entries which have the external code hr manager
EmpJobRelationships?
$filter=relationshipTypeNav/externalCode
eq 'hr manager'&
$expand=relationshipTypeNav&
$select=relationshipTypeNav/
externalCode,relationshipType&$format=JSON
Code Examples
{
"d": {
Related Information
6.8 EmpPensionPayout
This entity contains information about how the pension will be paid to the employee.
Operations Allowed
Operation Description
Properties
Table 84:
Property Description
createdOn The date that the pension payout information was added.
lastModifiedBy The ID of the person who made the lastest updated to the pen
sion payout information.
Table 85:
Navigation Property Related Entity Description
In Provisioning the following feature has to be enabled to make this entity visibile: "Enable Pension Payouts"
Related Information
6.9 EmpWfRequest
This entity contains information about workflow requests associated with an employee.
Operations Allowed
Table 86:
Operation Description
Properties
Table 87:
Property Description
empWfRequestId
actionType
effectiveDate
entityType
eventReason
requestType
subjectId
wfConfig
wfRequestId
Navigation Properties
Table 88:
Navigation Property Related Entity Description
Use Cases
Table 89:
API Call Description
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/EmpWfRequest(307L)",
"type": "SFOData.EmpWfRequest"
},
"eventReason": "PAYMKT",
"subjectId": "cgrant1"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/EmpWfRequest(306L)",
"type": "SFOData.EmpWfRequest"
},
"eventReason": "PAYMKT",
"subjectId": "cgrant1"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/EmpWfRequest(305L)",
"type": "SFOData.EmpWfRequest"
},
"eventReason": "PAYMKT",
"subjectId": "cgrant1"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/EmpWfRequest(304L)",
"type": "SFOData.EmpWfRequest"
},
"eventReason": "PAYMKT",
"subjectId": "cgrant1"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/EmpWfRequest(303L)",
"type": "SFOData.EmpWfRequest"
},
"eventReason": "PAYMKT",
"subjectId": "cgrant1"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/EmpWfRequest(302L)",
"type": "SFOData.EmpWfRequest"
},
"eventReason": "PAYMKT",
"subjectId": "cgrant1"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/EmpWfRequest(301L)",
"type": "SFOData.EmpWfRequest"
},
"eventReason": "PAYMKT",
"subjectId": "cgrant1"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/EmpWfRequest(41L)",
"type": "SFOData.EmpWfRequest"
},
Related Information
6.10 EmpWorkPermit
Operations Allowed
Operation Description
Table 91:
Property Description
documentType This is type of the document.The list of values comes from the
predefined cascading picklist permitdoctype, which is filtered
based on the country selected in the country field.
notes This is a text field where the user can enter additional informa
tion if required.
attachmentFileName You can upload a copy of the work permit document in differ
ent formats, for example, .doc, .ppt, .png, and so on. This is
the file name of the attachment.
attachmentFileType You can upload a copy of the work permit document in differ
ent formats, for example, .doc, .ppt, .png, and so on.
attachmentStatus
attachment
createdOn The date that the work permit information was added.
lastModifiedBy The ID of the person who made the lastest updated to the
work permit entry
customString(1,20) You can use these fields for data not covered by the fields sup
plied as standard.
customDate(1,10) You can use these fields for data not covered by the fields sup
plied as standard.
customLong(1,20) You can use these fields for data not covered by the fields sup
plied as standard.
customDouble(1,20) You can use these fields for data not covered by the fields sup
plied as standard.
attachmentId You can use these fields for data not covered by the fields sup
plied as standard.
Navigation Properties
Table 92:
Navigation Property Related Entity Description
Use Cases
Table 93:
API Call Description
Code Examples
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://<hostname>.com:443/odata/v2/
EmpWorkPermit(country='USA',documentNumber='gr',documentType='6148',userId='174')",
"type" : "SFOData.EmpWorkPermit"
}, "documentType" : "6148", "userId" : "174", "documentNumber" : "gr", "country" :
"USA", "attachmentFileSize" : "44711", "attachmentStatus" : "1", "expirationDate" :
"\/Date(1377129600000)\/", "attachmentFileName" : "EmeprgencyBeforeImport.jpeg",
Related Information
6.11 EmpPayCompNonRecurring
This enitity contains information about non-recurring components of the an employee's pay.
Operation Description
Properties
Table 95:
Property Description
sequenceNumber This field is used for internal purposes. Do not configure the
visibility.
currencyCode The currency the pay component is issued in. Select from the
list of currencies provided in this field.
taxTreatment This field is used for internal purposes. Do not configure the
visibility.
sentToPayroll This field is used for internal purposes. Do not configure the
visibility.
notes A text field where the user can enter additional information if
required.
formId
templateId
operation
lastModifiedBy The ID of the person who made the lastest updated to the en
try
Navigation Properties
Table 96:
Navigation Property Related Entity Description
‹‹ If necessary, add any supplementary information about the use cases here ››
Table 97:
API Call Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpPayCompNonRecurring(payComponentCode='BNS-
USA',payDate=datetime'2011-05-09T00:00:00',userId='mbarista1')",
"type": "SFOData.EmpPayCompNonRecurring"
},
"value": "20000",
"employmentNav": {
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpEmployment(personIdExternal='mbarista1',userId='mbarista1')",
"type": "SFOData.EmpEmployment"
},
"personNav": {
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
PerPerson('mbarista1')",
"type": "SFOData.PerPerson"
},
"personalInfoNav": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
public/
PerPersonal(personIdExternal='mbarista1',startDate=datetime'1990-01-01T00:00:00')",
"type": "SFOData.PerPersonal"
},
"lastName": "Barista",
"firstName": "Marcia"
}
]
}
}
}
}
]
}
}
6.12 EmpPayCompRecurring
Operations Allowed
Operation Description
Properties
Table 99:
Property Description
payComponent The pay component that makes up the employee's total com
pensation, like base salary. If you have defined pay component
foundation objects, this field contains the external code of
those pay components.
currencyCode This is the currency of the pay component. The values come
from the list of currencies.
frequency This is the frequency in which the pay component is paid, for
example, monthly, annual, bi-weekly, and so on. If you have
defined frequency foundation objects, this field contains the
external code of those frequencies.
notes This is a text field where the user can enter additional informa
tion if required.
formId
templateId
operation
createdOn The date that the pay component information was added.
lastModifiedBy The ID of the person who made the lastest updated to the
compensation entry
customString(1,20) You can use these fields for data not covered by the fields sup
plied as standard.
customDate(1,10) You can use these fields for data not covered by the fields sup
plied as standard.
customLong(1,20) You can use these fields for data not covered by the fields sup
plied as standard.
customDouble(1,20) You can use these fields for data not covered by the fields sup
plied as standard.
When you make a last modified query, take a look at how this entitiy behaves with $filter and lastModifiedOn:
Navigation Properties
Table 100:
Navigation Property Related Entity Description
Use Cases
‹‹ If necessary, add any supplementary information about the use cases here ››
Table 101:
API Call Description
https://<hostname>/odata/v2/ Get all Persons having a greater income than 100000 USD per
EmpPayCompRecurring?$filter=payComponent year
eq 'Base Salary' and paycompvalue ge
'100000' and currencyCode eq 'USD' and
frequency eq 'ANN'&$format=JSON
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpPayCompRecurring(payComponent='Base
Salary',seqNumber=1L,startDate=datetime'2011-03-19T00:00:00',userId='wsown1')",
"type": "SFOData.EmpPayCompRecurring"
},
"startDate": "/Date(1300492800000)/",
"payComponent": "Base Salary",
"userId": "wsown1",
"seqNumber": "1",
"paycompvalue": "100000",
"currencyCode": "USD",
"endDate": "/Date(253402300799000)/",
"frequency": "ANN",
"lastModifiedDateTime": "/Date(1304284880000+0000)/",
"lastModifiedOn": "/Date(1304284880000)/",
"createdOn": "/Date(1304284880000)/",
"createdBy": "wsown1",
"createdDateTime": "/Date(1304284880000+0000)/",
"lastModifiedBy": "wsown1",
"notes": null,
"frequencyNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpPayCompRecurring(payComponent='Base
Salary',seqNumber=1L,startDate=datetime'2011-03-19T00:00:00',userId='wsown1')/
frequencyNav"
}
},
"payComponentNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpPayCompRecurring(payComponent='Base
Salary',seqNumber=1L,startDate=datetime'2011-03-19T00:00:00',userId='wsown1')/
payComponentNav"
}
},
"compensationNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpPayCompRecurring(payComponent='Base
Salary',seqNumber=1L,startDate=datetime'2011-03-19T00:00:00',userId='wsown1')/
compensationNav"
}
},
"userNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpPayCompRecurring(payComponent='Base
Salary',seqNumber=1L,startDate=datetime'2011-03-19T00:00:00',userId='wsown1')/
userNav"
}
},
"employmentNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/public/
EmpPayCompRecurring(payComponent='Base
Salary',seqNumber=1L,startDate=datetime'2011-03-19T00:00:00',userId='wsown1')/
employmentNav"
}
Related Information
6.13 EmpTimeAccountBalance
The EmpTimeAccountBalance entity provides time account balance information, enabling external systems like
payrolls to capture this data. The most common use case for deriving time account balance information is to
enrich the employee’s pay slip with time off data.
As the balance is not stored in EC Time Off, the API needs to calculate the balance as of the specified date (balance
as of date). The API therefore needs to determine the valid time account(s) of the respective user (that is,
employment) and time account type and calculate the balance by summing up the time account details.
The API currently returns only calculated data based on accrual runs already performed. Simulated data is not
returned by the API.
For details, check the corresponding Implementation Information for Time Off available at http://help.sap.com/
cloud4hr?current=on-demand#section5.
Note
Example
If the service is called with a balance as of date 1.3.2014, the system identifies two valid time accounts and
returns both results. Result would be 2 records as above.
If the service is called with a balance as of date 1.8.2014, the system identifies only one valid time account.
Result would be 18 days. One record is returned only.
Permissions
Ensure that for Manage Integration Tools the following checks are switched on:
Ensure that for Employee Central API the following checks are switched on:
Operations Allowed
Table 102:
Operation Description
Required Fields
The Entity has two mandatory filters, to be used in $filter, which support IN and EQ operation only. The 2nd
optional parameter is a normal URL parameter which requires a date in format YYYY-MM-DD.
Name Description
timeAccountType (mandatory) – as part of $filter List of Time Account Type(s). Error if no time account type is
provided.
balanceAsOfDate (optional) – URL parameter Balances as of Date If no date is passed, today will be used as
the default effective date
Caution
When you are using this entity in middleware or integration center, bulk data abstraction is not possible because
UserID is a mandatory field and giving all UserID in the filter criteria will lead to a large query that would result in
a failure.
Properties
The following properties are returned for each record. The API might return several records per user and time
account type provided in the filter. The unique key of the returned records is neither the userId nor the
timeAccountType but the unique UUID of the TimeAccount Entity. This means that the API returns the balance for
all relevant time accounts of the given users and adds additional information based on the returned time account.
Table 104:
Property Description
Navigation Properties
No navigation properties.
Example: Payroll Integration - provide time account balance information for pay slip
https://salesdemo4.successfactors.com/odata/v2/EmpTimeAccountBalance
?$filter=userId+in+'btassimo','bwfapproval'+and
+timeAccountType+in+'bgs_tacct_irregularWorkSchedule_hours',
'bgs_tacct_WF_NoStep_CcRole-Person',
'bgs_tacct_WF_stepEM_CcEMM',
'bgs_tacct_WF_NoStep_CcDynamicGroup',
'bgs_tacct_WF_NoStep_CcDynamicRole'
&$format=JSON
&balanceAsOfDate=2014-09-01
Results
{"d" : {"results" : [
{
"__metadata" : {
"uri" : "https://salesdemo4.successfactors.com/odata/v2/
EmpTimeAccountBalance('168c659421714e16bcd1963d9937731b')", "type" :
"SFOData.EmpTimeAccountBalance"
}, "timeAccount" : "168c659421714e16bcd1963d9937731b", "balance" : "240",
"userId" : "btassimo", "timeUnit" : "HOURS", "accountClosed": false,
"timeAccountType" : "bgs_tacct_irregularWorkSchedule_hours"
}, {
}, {
"__metadata" : {
"uri" : "https://salesdemo4.successfactors.com/odata/v2/
EmpTimeAccountBalance('b081c83b83c6472fa0920bd47057f74c')", "type" :
"SFOData.EmpTimeAccountBalance"
}, "timeAccount" : "b081c83b83c6472fa0920bd47057f74c", "balance" : "-4.2166666667",
"userId" : "bwfapproval", "timeUnit" : "HOURS", "accountClosed": false,
"timeAccountType" : "bgs_tacct_WF_stepEM_CcEMM"
}, {
"__metadata" : {
"uri" : "https://salesdemo4.successfactors.com/odata/v2/
EmpTimeAccountBalance('03f7b8cd4fac41f08a0d44f3f38eb015')", "type" :
"SFOData.EmpTimeAccountBalance"
}, "timeAccount" : "03f7b8cd4fac41f08a0d44f3f38eb015", "balance" : "39.75",
"userId" : "bwfapproval", "timeUnit" : "DAYS", "accountClosed": false,
"timeAccountType" : "bgs_tacct_WF_NoStep_CcRole-Person"
}
]}}
{"d" : {"results" : [
{
"__metadata" : {
"uri" : "https://salesdemo4.successfactors.com/odata/v2/
EmpTimeAccountBalance('168c659421714e16bcd1963d9937731b')", "type" :
"SFOData.EmpTimeAccountBalance"
}, "timeAccount" : "168c659421714e16bcd1963d9937731b", "balance" : "240",
"userId" : "btassimo", "timeUnit" : "HOURS", "accountClosed": false,
"timeAccountType" : "bgs_tacct_irregularWorkSchedule_hours"
}, {
}, {
"__metadata" : {
Error Handling
Invalid userIds or Time Account Types are not reported as errors and will just lead to an empty result set.
6.14 SecondaryAssignments
You use this entity to differentiate primary from secondary employments during concurrent employment
replications.
Operations Allowed
Table 105:
Operation Description
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/
Entity('SecondaryAssignments')?$format=json
Operation GET
URI https://<hostname>.com/odata/v2/PerPerson?
$format=json&$filter=personIdExternal%20eq
%20'jsmith'&
$expand=secondaryAssignmentsNav/
allSfProcesses
Response
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com/odata/v2/PerPerson('jsmith')",
"type": "SFOData.PerPerson"
},
"personIdExternal": "jsmith",
"dateOfBirth": null,
"lastModifiedOn": "/Date(1303743709000)/",
"lastModifiedDateTime": "/Date(1303743709000+0000)/",
"dateOfDeath": null,
"createdOn": "/Date(1303743708000)/",
"countryOfBirth": null,
"createdBy": "v4admin",
"regionOfBirth": null,
"createdDateTime": "/Date(1303743708000+0000)/",
"lastModifiedBy": "v4admin",
"personId": "11",
"personRerlationshipNav": {
"__deferred": {
"uri": "https://<hostname>.com/odata/v2/
PerPerson('jsmith')/personRerlationshipNav"
}
},
"emergencyContactNav": {
"__deferred": {
"uri": "https://<hostname>.com/odata/v2/
PerPerson('jsmith')/emergencyContactNav"
}
"SecondaryAssignments_effectiveStartDate": "/Date(1466726400000)/",
"externalCode":
"c95d6999d02e46878dcad5ef2a02397c",
"mdfSystemEffectiveEndDate": "/
Date(253402214400000)/",
"mdfSystemObjectType":
"SecondaryAssignmentsItem",
"mdfSystemVersionId": null,
"lastModifiedDateTime": "/
Date(1467020470000+0000)/",
"usersSysId": "181",
"mdfSystemTransactionSequence": "1",
"createdBy": "admin",
"mdfSystemRecordId":
"448E51556F414997A79F1360D837CD29",
"mdfSystemEntityId":
"DCAF412BC16D46408FB7D3EEDB7DDF63",
"createdDateTime": "/
Date(1467020470000+0000)/",
"lastModifiedBy": "admin",
"mdfSystemStatus": "A",
"lastModifiedDate": "/
Date(1467020470000)/",
"mdfSystemEffectiveStartDate": "/
Date(-2208988800000)/",
"lastModifiedDateWithTZ": "/
Date(1467020470000+0000)/",
"createdDate": "/Date(1467020470000)/",
"mdfSystemRecordStatus": "N",
"usersSysIdNav": {
"__deferred": {
"uri": "https://<hostname>.com/
odata/v2/
SecondaryAssignmentsItem(SecondaryAssignments_effectiveStartDate=datetime'2016-06-
24T00:00:00',SecondaryAssignments_externalCode='jsmith',externalCode='c95d6999d02e
46878dcad5ef2a02397c')/usersSysIdNav"
}
},
"mdfSystemRecordStatusNav": {
"__deferred": {
"uri": "https://<hostname>.com/
odata/v2/
SecondaryAssignmentsItem(SecondaryAssignments_effectiveStartDate=datetime'2016-06-
24T00:00:00',SecondaryAssignments_externalCode='jsmith',externalCode='c95d6999d02e
46878dcad5ef2a02397c')/mdfSystemRecordStatusNav"
}
},
"mdfSystemStatusNav": {
"__deferred": {
"uri": "https://<hostname>.com/
odata/v2/
SecondaryAssignmentsItem(SecondaryAssignments_effectiveStartDate=datetime'2016-06-
24T00:00:00',SecondaryAssignments_externalCode='jsmith',externalCode='c95d6999d02e
46878dcad5ef2a02397c')/mdfSystemStatusNav"
}
}
}
]
},
"mdfSystemRecordStatusNav": {
"__deferred": {
"uri": "https://<hostname>.com/odata/v2/
SecondaryAssignments(effectiveStartDate=datetime'2016-06-24T00:00:00',externalCode
='jsmith')/mdfSystemRecordStatusNav"
}
Related Information
A composite child of SecondaryAssignments. It can only be upserted with SecondaryAssignments. Along with
SecondaryAssignments, it captures concurrent employment information. To be precise, the PerPerson entity has
a navigation secondayAssignmentsNav that lets you navigate to the entity SecondaryAssignments.
Operations Allowed
Table 107:
Operation Description
Although all operations are supported, the only one that makes any business sense is upsert.
Properties
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Upsert Operation: Retrieves the secondaryAssignmentsNav which in turn will return the
SecondaryAssignmentsItems, that is information about the secondary employment. There is not often a business
case for this operation but it has been provided to support the cloning or transfer of data between similar
instances in a different environment. In this example here, user system ID (represented by the externalcode)for
the primary employment is PrimaryEmployment and the userSysID for secondary employment is represented by
301 (a number automatically generated when a secondary employment is created)
Request: https://<hostname>.com/odata/v2/upsert
Payload Data
{
"__metadata": { "uri": "SecondaryAssignments"},
"effectiveStartDate" : "/Date(1420066800000)/",
"externalCode" : "mjaschob",
"allSfProcesses": {
"__metadata": { "uri": "SecondaryAssignmentsItem"},
"SecondaryAssignments_effectiveStartDate" : "/Date(1420066800000)/",
"SecondaryAssignments_externalCode" : "mjaschob",
"externalCode" : "myexternalcode55",
"usersSysId" : "301"
}
}
Additional Information
You can see an example of SecondaryAssigmentsItem in use in Differentiating primary from secondary
employment during concurrent employment replication [page 587]
Related Information
7.1 FiscalYearToCountryMap
This entity is used to map the fiscal year variant created for income tax declarations to a country.
Operations Allowed
Table 108:
Operation Description
Properties
Table 109:
Property Description
Navigation Properties
Table 110:
Navigation Property Related Entity Description
Table 111:
API Call Description
7.2 FiscalYearVariant
This entity is the fiscal year variant created for income tax declarations.
Operations Allowed
Table 112:
Operation Description
Properties
Table 113:
Property Description
Navigation Properties
None.
Table 114:
API Call Description
Flexible associations can be defined between two foundation objects in the Corporate Data Model. The example
below shows a one to one relationship between location and geozone; a one to many relationship is defined
between location and company. OData automatically creates navigations from the source entity to the target
entities, based on the relationship defined.
<hris-element id="location">
<hris-associations>
<association id="id" multiplicity="ONE_TO_ONE" destination-
entity="geozone"/>
<association id="id" multiplicity="ONE_TO_MANY" destination-
entity="company"/>
</hris-associations>
</hris-associations>
The diagram below shows the default relationships between the different OData entities.
8.2 FODynamicRole
Table 115:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 116:
Property Description
createdOn The date that the dynamic role information was added.
createdBy The ID of the person who created the dynamic role entry.
lastModifiedOn The date that the dynamic role information was modified.
lastModifiedBy The ID of the person who made the lastest updated to the dynamic role entry.
eventReason
payGroup An ID that represents a group of people who share the same payroll attributes.
Navigation Properties
Table 117:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Use Cases
‹‹ If necessary, add any supplementary information about the use cases here ››
Table 118:
API Call Description
Code Examples
This entity contains event reasons used to define a reason for changing employee data. Event reasons are related
to events defined in the PickListV2 entity and have an employee status assigned.
Operations Allowed
Operation Description
Properties
Table 119:
Property Description
includeInWorkExperience Defines if an event reason is displayed in the Internal Job History portal.
payrollEvent A field for the SAP ERP payroll events that are not delivered by SuccessFactors.
createdBy The ID of the person who created the event reason entry.
lastModifiedOn The date that the event reason information was modified.
lastModifiedBy The ID of the person who made the last update to the event reason entry.
Navigation Properties
Table 120:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Use Cases
Table 121:
API Call Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
8.4 FOFrequency
Operations Allowed
Table 122:
Operation Description
Table 123:
Property Description
lastModifiedBy The ID of the person who made the last update to the frequency entry.
Navigation Properties
Table 124:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Use Cases
Table 125:
API Call Description
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/FOFrequency('DLY')",
"type": "SFOData.FOFrequency"
},
"externalCode": "DLY",
"description": "Daily",
"name": "Daily",
"annualizationFactor": "365"
}
]
}
}
8.5 FOGeozone
Operations Allowed
Table 126:
Operation Description
Table 127:
Property Description
adjustmentPercentage The percentage of the difference in a pay range from one geozone to another.
lastModifiedBy The ID of the person who made the last update to the geozone entry.
Navigation Properties
Table 128:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Table 129:
API Call Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
FOGeozone(externalCode='APAC',startDate=datetime'1990-01-01T00:00:00')",
"type": "SFOData.FOGeozone"
},
"createdBy": "admin",
"status": "A",
"name": "Asia Pacific"
}
]
}
}
8.6 FOLocation
Operations Allowed
Table 130:
Operation Description
Properties
Table 131:
Property Description
lastModifiedBy The ID of the person who made the last update to the location entry.
Table 132:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
addressNavDEFLT FOCorporateAddressDEFLT
Use Cases
Table 133:
API Call Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
FOLocation(externalCode='KO_SEO',startDate=datetime'1990-01-01T00:00:00')",
"type": "SFOData.FOLocation"
},
"startDate": "/Date(631152000000)/",
"externalCode": "KO_SEO",
"status": "A",
"endDate": "/Date(253402300799000)/",
"lastModifiedDateTime": "/Date(1317104275000+0000)/",
"lastModifiedOn": "/Date(1317104275000)/",
"createdOn": "/Date(1300819181000)/",
"timezone": "Asia/Seoul",
"createdBy": "admin",
"geozoneFlx": "APAC",
"description": "Seoul, Korea",
"name": "Seoul",
"createdDateTime": "/Date(1300819181000+0000)/",
"lastModifiedBy": "admin",
"locationGroup": "APAC",
"standardHours": null,
"geozoneFlxNav": {
"__deferred": {
8.7 FOLocationGroup
Operations Allowed
Table 134:
Operation Description
Properties
Table 135:
Property Description
createdOn The date that the location group information was added.
createdBy The ID of the person who created the location group entry.
lastModifiedOn The date that the location group information was modified.
lastModifiedBy The ID of the person who made the last update to the location group entry.
Navigation Properties
Table 136:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Use Cases
Table 137:
API Call Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
8.8 FOPayComponent
Operations Allowed
Table 138:
Operation Description
Table 139:
Property Description
selfServiceDescription Indicates if the a pay component description is displayed in the manager self-serv
ice.
usedForCompPlanning Indicates if the pay component is used by the comp module. The values are None,
Comp, Varpay, and Both.
target A Yes or No indication that determines if the pay component is a target amount.
maxFractionDigits
createdOn The date that the pay component information was added.
createdBy The ID of the person who created the pay component entry.
lastModifiedOn The date that the pay component information was modified.
lastModifiedBy The ID of the person who made the last update to the pay component entry.
Table 140:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Use Cases
Table 141:
API Call Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
FOPayComponent(externalCode='Base Salary',startDate=datetime'1970-01-01T00:00:00')",
"type": "SFOData.FOPayComponent"
},
"startDate": "/Date(0)/",
"externalCode": "Base Salary",
"basePayComponentGroup": null,
"usedForCompPlanning": "COMP",
"payComponentType": "AMOUNT",
"endDate": "/Date(253370764800000)/",
"lastModifiedDateTime": "/Date(1304801484000+0000)/",
"currency": "USD",
"selfServiceDescription": null,
"isEarning": true,
"description": "Base Salary for USA",
"name": "Base Salary",
"recurring": true,
"status": "A",
"lastModifiedOn": "/Date(1304787084000)/",
8.9 FOPayComponentGroup
Operations Allowed
Table 142:
Operation Description
Properties
Table 143:
Property Description
showOnCompUI Indicates if the pay component group is displayed on the Comp UI.
useForComparatioCalc Indicates if the the pay component group is used for the comp ratio calculation.
useForRangePenetration Indicates if the pay component group can be used to determine how far into a given
pay range an employee has progressed.
sortOrder
createdOn The date that the pay component group information was added.
createdBy The ID of the person who created the pay component group entry.
lastModifiedOn The date that the pay component group information was modified.
lastModifiedBy The ID of the person who made the last update to the pay component group entry.
Table 144:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Use Cases
Table 145:
API Call Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
FOPayComponentGroup(externalCode='Base
Salary',startDate=datetime'1970-01-01T00:00:00')",
"type": "SFOData.FOPayComponentGroup"
},
"externalCode": "Base Salary"
}
]
}
}
8.10 FOPayGrade
Table 146:
Operation Description
Properties
Table 147:
Property Description
createdOn The date that the pay grade information was added.
createdBy The ID of the person who created the pay grade entry.
lastModifiedOn The date that the pay grade information was modified.
lastModifiedBy The ID of the person who made the last update to the pay grade entry.
Navigation Properties
Table 148:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Use Cases
Table 149:
API Call Description
https://<hostname>.com/odata/v2/ Get all PayGrades with the status A and the externalCode XXX
FOPayGrade?$filter=status eq 'A' and
externalCode eq 'GR-1'&$format=JSON
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
FOPayGrade(externalCode='GR-1',startDate=datetime'1990-01-01T00:00:00')",
"type": "SFOData.FOPayGrade"
},
"startDate": "/Date(631152000000)/",
"externalCode": "GR-1",
"createdOn": "/Date(1320750704000)/",
"createdBy": "admin",
"status": "A",
"description": null,
"paygradeLevel": "1",
"name": "Salary Grade 1",
"lastModifiedBy": "admin",
"createdDateTime": "/Date(1320768704000+0000)/",
"endDate": "/Date(253402214400000)/",
"lastModifiedOn": "/Date(1320750704000)/",
"lastModifiedDateTime": "/Date(1320768704000+0000)/"
}
]
8.11 FOPayRange
Operations Allowed
Table 150:
Operation Description
Properties
Table 151:
Property Description
createdOn The date that the pay range information was added.
createdBy The ID of the person who created the pay range entry.
lastModifiedOn The date that the pay range information was modified.
lastModifiedBy The ID of the person who made the last update to the pay range entry.
Navigation Properties
Table 152:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Use Cases
‹‹ If necessary, add any supplementary information about the use cases here ››
Table 153:
API Call Description
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
FOPayRange(externalCode='PR-1-EU',startDate=datetime'1990-01-01T00:00:00')",
"type": "SFOData.FOPayRange"
},
"startDate": "/Date(631152000000)/",
"externalCode": "PR-1-EU",
"minimumPay": "7146",
"status": "A",
"endDate": "/Date(253402214400000)/",
"lastModifiedOn": "/Date(1311238423000)/",
"lastModifiedDateTime": "/Date(1311252823000+0000)/",
"midPoint": "10718.5",
"companyFlx": null,
"currency": "USD",
"createdOn": "/Date(1300225256000)/",
"createdBy": "admin",
"payGradeFlx": "GR-12",
"geozoneFlx": "EMEA",
"description": null,
"frequencyCode": "ANN",
"name": "Pay Range 1-3",
"createdDateTime": "/Date(1300239656000+0000)/",
"lastModifiedBy": "admin",
"maximumPay": "14291",
"geozoneFlxNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/
FOPayRange(externalCode='PR-1-EU',startDate=datetime'1990-01-01T00:00:00')/
geozoneFlxNav"
}
},
"frequencyCodeNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/
FOPayRange(externalCode='PR-1-EU',startDate=datetime'1990-01-01T00:00:00')/
frequencyCodeNav"
}
},
"payGradeFlxNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/
FOPayRange(externalCode='PR-1-EU',startDate=datetime'1990-01-01T00:00:00')/
payGradeFlxNav"
}
},
"companyFlxNav": {
"__deferred": {
"uri": "<hostname>.com:443/odata/v2/
FOPayRange(externalCode='PR-1-EU',startDate=datetime'1990-01-01T00:00:00')/
companyFlxNav"
}
}
}
]
}
}
Operations Allowed
Table 154:
Operation Description
Properties
You can get detailed information about the entity properties in your instance from the OData API dictionary or by
exposing the entity metadata. To do this, use the following query https://<hostname>/odata/v2/
Entity('<Your Entity')?$format=json. This list here highlights some of the properties.
Table 155:
Property Description
remindIndays The number of days after which the workflow approver is reminded to take action
on a pending workflow.
is_delegate_supported A Yes or No indicator that enables manual delegation or auto delegation of work
flows.
stepNum
actionType The type of edit a step approver can make to the workflow. The types are No Edit,
Edit with Route Change, and Edit without Route Change.
approverRole The person who approves the workflow. The approvers are Employee, Employee
Manager, Employee Manager Manager, Employee HR Matrix Manager, Custom
Manager, Second Manager, and Additional Manager.
futureDatedAlternateWorkflow
approverType The approver type is Role, Dynamic Role, Dynamic Group, and Position.
context Defines which manager is authorized to approve a change. The types are Source
and Target.
skipType Defines how the system should react when there is an empty position or dynamic
group. The types are Stop the Workflow and Skip this Step.
respectRBP
createdOn The date that the workflow configuration information was added.
createdBy The ID of the person who created the workflow configuration entry.
lastModifiedOn The date that the workflow configuration information was modified.
lastModifiedBy The ID of the person who made the last update to the workflow configuration entry.
Navigation Properties
Table 156:
Navigation Property Related Entity Description
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
Table 157:
API Call Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
FOWfConfig('GRT_TEST')",
"type": "SFOData.FOWfConfig"
},
"externalCode": "GRT_TEST",
"createdOn": "/Date(1379578155000)/",
"futureDatedAlternateWorkflow": null,
"createdBy": "admin",
"description": "GRT_TEST",
"name": "GRT_TEST",
"lastModifiedBy": "admin",
"createdDateTime": "/Date(1379592555000+0000)/",
"lastModifiedOn": "/Date(1379578155000)/",
"lastModifiedDateTime": "/Date(1379592555000+0000)/",
"futureDatedAlternateWorkflowNav": {
"__deferred": {
"uri": "https://<hostname>.com:443/odata/v2/
FOWfConfig('GRT_TEST')/futureDatedAlternateWorkflowNav"
}
}
}
]
}
}
Operations Allowed
Table 158:
Operation Description
Properties
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json.
Use Cases
You can use this entity to get detailed workflow information about these fields:
● actionType
● approverPositionRelationship
● approverType
● approverRole
● context
● relationshipToApprover
● respectRBP
● skipType
Operation GET
URI http://<Hostname>/odata/v2/
FOWfConfigStepApprover
Sample Code
Extract from response
....
<entry>
<id>https://<hostname>.com/odata/v2/
FOWfConfigStepApprover(externalCode='LOA',stepNum=1L)</id>
<title type="text"></title>
<updated>2016-10-11T08:22:03Z</updated>
<author>
<name></name>
</author>
<link rel="edit" title="FOWfConfigStepApprover"
href="FOWfConfigStepApprover(externalCode='LOA',stepNum=1L)"></link>
<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/
approverDynamicRoleNav" type="application/atom+xml;type=feed"
title="approverDynamicRoleNav"
href="FOWfConfigStepApprover(externalCode='LOA',stepNum=1L)/
approverDynamicRoleNav"></link>
<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/
approverGroupNav" type="application/atom+xml;type=entry" title="approverGroupNav"
href="FOWfConfigStepApprover(externalCode='LOA',stepNum=1L)/approverGroupNav"></
link>
<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/
approverPositionNav" type="application/atom+xml;type=feed"
title="approverPositionNav"
href="FOWfConfigStepApprover(externalCode='LOA',stepNum=1L)/
approverPositionNav"></link>
<category term="SFOData.FOWfConfigStepApprover" scheme="http://
schemas.microsoft.com/ado/2007/08/dataservices/scheme"></category>
<content type="application/xml">
<m:properties>
<d:stepNum m:type="Edm.Int64">1</d:stepNum>
<d:externalCode>LOA</d:externalCode>
<d:approverPositionRelationship m:null="true"></
d:approverPositionRelationship>
<d:lastModifiedDateTime
m:type="Edm.DateTimeOffset">2011-12-06T18:34:27Z</d:lastModifiedDateTime>
<d:actionType>NO_EDIT</d:actionType>
<d:skipType m:null="true"></d:skipType>
<d:approverRole>EH</d:approverRole>
<d:relationshipToApprover m:null="true"></
d:relationshipToApprover>
<d:approverType>ROLE</d:approverType>
<d:createdBy>admin</d:createdBy>
<d:lastModifiedBy>admin</d:lastModifiedBy>
<d:createdDateTime
m:type="Edm.DateTimeOffset">2011-07-28T00:28:27Z</d:createdDateTime>
<d:context>SOURCE</d:context>
<d:respectRBP m:null="true"></d:respectRBP>
<d:relationshipToPosition m:null="true"></
d:relationshipToPosition>
</m:properties>
</content>
</entry>
You can either query this entity directly as described above or via $expand=wfStepApproverNav from
FOWfConfig.
Related Information
As part of the phased migration of Foundation Objects (FO) to Metadata Framework (MDF), the FOs Cost Center,
Business Unit, Division, Department, Legal Entity, Job Classification, Job Function, Job Family, Pay Group, and
PayCalendar have been migrated. After migration, these FOs are now Generic Objects.
For these newly created GOs, you can influence the way the fields behave in API queries. For example, if Division
was not mapped, it would be displayed as any other MDF OData source, and you would still have the field
effectiveStartDate in the API query. In element field mapping, effectiveStartDate is mapped to the HRIS element ID
start-date. Here, we are telling the system that the original field name for effectiveStartDate is startdate. Likewise,
effectiveStatus is mapped to status, cust_string1 is mapped to custom_string1, cust_string2 is mapped to
custom_string2, and so on.
Let’s see how it works for the various fields. The system searches the object definition and then the element type
map. If there is a mapping in the Element Type Map (see Element Field Map for EC Migration section), it displays
the field name from the map. For example, you define a new custom field called cust_string7.
There are a few special handlings. In object definition, if you map a field that is translatable, for example, name or
description, the behavior is the same as it was earlier. You will also have the field with the element map name.
Additionally, you will have this field with the suffix for the language.
You have a picklist field and now you define a field in the object definition, for example, cust_string4 is mapped to
custom-string4.
If the element type map does not have cust_string4, that is, if it is not mapped there, you still have the cust_string4
and cust_string4Nav fields.
The two extra fields will not be available now since there is no mapping.
Before the migration, migrated FOs exposed language-independent texts for Name and Description. In addition, it
provided two links to FOTranslation to find the language-dependent texts for both fields. For example, the Odata
entities FOJobFunction and FOPayGroup provided the navigation attributes nameTranslationNav and
descriptionTranslationNav to FoTranslation, if the translation of FOs is activated in Provisioning.
After the migration, Name and Description will still be available for migrated FOs,to expose language-independent
texts. In addition, the two navigation attributes will also be available. However, they will not be really linked to
FOTranslation, but will always return an empty value. So the language-dependent texts will be integrated as
additional attributes into the migrated FO Odata entity (for example FOJobFunction, FOPayGroup) in the standard
MDF way.
If you are not using FOTranslation for migrated FOs, de-select the FOTranslation navigation in Boomi. In case you
are using FOTranslation for migrated FOs, you need to adapt the UI.
The element type mapping shows the mapping between HRIS field names and field names for the GOs. The steps
to view the element type mapping for a migrated Foundation Object are described below.
Note
Not everyone can view the element Element Type Mapping. To grant permission, the steps are as follows:
You can use the OData API dictionary to view information specific to an API entity. To view the OData API
dictionary:
Note that if you you have made changes to the object definition or the mapping, you must have refreshed the
OData metadata to see the changes.
8.14.2 Associations
Let’s say, in the object definition you have an association defined. The association is called cust_toLegalEntity and
the definition is called Legal Entity. In the Element Type map (under Element Association Map for EC Migration
section), you have the association name cust_toLegalEntity, which is mapped to HRIS destination entity company.
This association is handled in the same way as an association for an FO is defined in the Corporate Data Model.
This means that you have the fields companyFlx and companyFlxNav in OData object definition. These fields will be
available only if the association defined in the object definition is added to the Association Element Type map.
For GO associations, if the field is not in the association mapping, you will only have the field that has the same
name as the association, for example, cust_toLegalEntity. This field can be queried and upserted. If this field is
added to the element association map, you will have the fields companyFlxNav and companyFlx for query and
upsert respectively.
If you want to add an association or a field, and want the field to behave in the same way as before the migration,
you must manually adjust the mapping objects.
Country-specific fields are fields of an object that are only relevant for specific countries. For example, for legal
entities in the US, you have to specify a Federal Reserve Bank ID, which is not relevant for legal entities in other
countries.
The only migrated FOs, which have country-specific fields, are Legal Entity (company) and Job Classification
(jobCode).
In OData (as well as the MDF object model), these fields are not stored directly in the main entity (FO Company or
FO Job Code). Instead, they are part of additional country-specific entities (see the sections LegalEntity<Country>
and JobClassification<Country>). These country-specific entities can be reached from the main entity using
navigation attributes.
Points to note:
● For FO Company, the navigation attributes for the delivered country specializations follow the naming
conventions toLegalEntity<Country> (see the section FOCompany).
● For FO Job Code, there is an intermediate entity JobClassificationCountry (see the section
JobClassificationCountry).
So for example, you can reach the France-specific fields of a job classification along the path FOJobCode/
toJobClassificationCountry/toJobClassificationFRA.
These navigation attributes and entity names differ from the legacy names. To ensure backward compatibility, you
can activate the old behavior for individual countries by maintaining the localization map in the element type map.
The following is an example of the element type map of Legal Entity (company):
Here, the localization map is maintained for two countries (USA and Germany). The effect of this is that, for these
two countries, additional navigation attributes and target entities will be available in addition to the standard
navigation attributes and entities described above. For USA, the effects are as follows:
● In addition to the standard entity LegalEntityUSA, there will be the backward-compatible entity
FOLegalEntityLocalUSA. This means that the MDF object LegalEntityUSA has two different OData
representations.
Similarly, if you maintain the localization map for USA in the element type map of Job Classification (jobCode), the
effects are as follows:
● In addition to the standard entity JobClassificationUSA, there will be the backward-compatible entity
FOJobCodeLocalUSA. These are different representations of the same MDF object JobClassificationUSA.
● In addition to the standard navigation chain toJobClassificationCountry/toJobClassificationUSA
(with target JobClassificationUSA), there is a shortcut navigation attribute called localNavUSA (with target
FOJobClassLocalUSA).
If you do not maintain an element type map, you have the following localization mapping that is used (as a fall
back):
GO Association Country
toLegalEntityARG ARG
toLegalEntityDEU DEU
toLegalEntityESP ESP
toLegalEntityFRA FRA
toLegalEntityUSA USA
GO Association Country
toJobClassificationCountry.toJobClassificationAUS AUS
toJobClassificationCountry.toJobClassificationBRA BRA
toJobClassificationCountry.toJobClassificationCAN CAN
toJobClassificationCountry.toJobClassificationFRA FRA
toJobClassificationCountry.toJobClassificationGBR GBR
toJobClassificationCountry.toJobClassificationITA ITA
toJobClassificationCountry.toJobClassificationUSA USA
To add country-specific fields for a new country, refer to the section Adding Country-Specific Fields for a New
Country.
If you need the backward-compatible OData representation for a country added in this way, you must do the
following:
● Maintain an entry in the localization map of the host element type map.
For this, you must add the association name for the new country and the ISO country code for it.
● Create an element type map for the new MDF object that you have created.
In the example for India (as in section Adding Country-Specific Fields for a New Country), you must add the
following:
Assume that you want to add country-specific fields for a new country, let us take India.You need to follow these
steps:
Procedure
To assign the new country object to Legal Entity, the steps are as follows:
Procedure
Assume that you want to add country-specific fields for a new country, let us take Spain.You need to follow these
steps:
Procedure
To assign the new country object to JobClassificationCountry, the steps are as follows:
Procedure
Let's take an example. The FO Business Unit is associated to Legal Entity and you have an association to company
1. You do an upsert by specifying the start date and external code of the business unit. In this case, either the
business unit is changed or a new one is created. Additionally, you list down the field that you want to change, for
example, companyFlx for company 2 and a pipe-separated list of the association target for company 3. Now the
existing association to company 1 is replaced and you have an association to company 2.
However, if you do an upsert through the MDF field cust_toLegalEntity, and specify company 1 and company 2, you
will have three associations. The upsert through the MDF field will only add or merge the existing ones.
Hence for example, Position will behave in the MDF way (merge behavior), and Job Classification, which is not on
MDF, will behave in the other manner (replacement).
8.14.5 CurrencyExchangeRate
The OData API entity CurrencyExchangeRate provides information about currency conversions in Employee
Central. It is based on the MDF object Currency Exchange Rate.
The source currency is 1 unit of USD and the target currency is 1 unit of CAD. The exchange rate shows how much
of the target currency (CAD) is needed to purchase one unit of the source currency (USD). Therefore, if the
exchange rate is 1.0950, it costs 1.0950 Canadian dollars to purchase 1 U.S. dollar.
The currency exchange rate type DEFAULT corresponds to the Compensation legacy currency conversion table
ECT_CONV_TABLE. The currency exchange rate type is defined as a picklist.
Operations Allowed
Operation Description
MDF Object:CurrencyExchangeRate
Business Keys:sourceCurrency,targetCurrency,currencyExchangeRateType
Required
Fields:sourceCurrency,targetCurrency,effectiveStartDate,exchangeRate,currencyExchang
eRateType
Full Purge:Yes
Incremental Purge:Yes
Effective-date:true
Navigation Properties
sourceCurrencyNav Currency
targetCurrencyNav Currency
currencyExchangeRateTypeNav PickListValueV2
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/CurrencyExchangeRate?
$format=json&$select=externalCode&$top=3
Response
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://localhost:443/odata/v2/
CurrencyExchangeRate(effectiveStartDate=datetime'1900-01-01T00:00:00',externalCode
='DEFAULT-ARS-MYR')",
"type": "SFOData.CurrencyExchangeRate"
},
Operation Query
Request https://<localhost:port>/odata/v2/
CurrencyExchangeRate(externalCode='DEFAULT-USD-
EUR',effectiveStartDate=datetime'1900-01-01T00:00:00')?
$format=json
Response
Sample Code
{
"d": {
"__metadata": {
"uri": "https://localhost:443/odata/v2/
CurrencyExchangeRate(effectiveStartDate=datetime'1900-01-01T00:00:00',externalCode
='DEFAULT-USD-EUR')",
"type": "SFOData.CurrencyExchangeRate"
},
"effectiveStartDate": "\/Date(-2208988800000)\/",
"externalCode": "DEFAULT-USD-EUR",
"exchangeRate": "1.125",
"targetCurrency": "EUR",
"effectiveStatus": "A",
"sourceCurrency": "USD",
"currencyExchangeRateType": "DEFAULT",
"sourceCurrencyNav": {
"__deferred": {
"uri": "https://localhost:443/odata/v2/
CurrencyExchangeRate(effectiveStartDate=datetime'1900-01-01T00:00:00',externalCode
='DEFAULT-USD-EUR')/sourceCurrencyNav"
}
},
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Response
Sample Code
Operation Delete
Request https://<localhost:port>/odata/v2/
CurrencyExchangeRate(externalCode='DEFAULT-USD-
EUR',effectiveStartDate=datetime'1900-01-01T00:00:00')
Response
Sample Code
Error Messages
The table below lists the error messages generated when using this API:
WORKSTRUCTURE_VALIDATION_IDENTICAL_SOURCE_TAR Exchange rate with the same source currency and target
GET_CURRENCIES_NOT_ALLOWED
currency is not allowed.
WORKSTRUCTURE_VALIDATION_REVERSE_RATE_OF_CUR A reverse exchange rate with source currency USD and target
RENCY_PAIR_ALREADY_EXISTS
currency EUR of currency exchange rate type DEFAULT
already exists.
8.14.6 FOBusinessUnit
Operations Allowed
Operation Description
Object Information
MDF Object:BusinessUnit
Business Keys: externalCode + startDate
Effective-date:true
Properties
The table below provides the mapping between attributes in OData and ODefinition fields. For more information
about the object definition fields, see the Data Object Tables for Business Unit in the Employee Central Master.
Table 160:
Property Name in OData Corresponding Field in Ob Comments
ject Definition
createdOn createdDate The date that the business unit information was added
createdDateTime createdDate
createdBy createdBy The ID of the person who created the business unit entry
lastModifiedOn lastModifiedDate The date that the business unit information was modified
lastModifiedDateTime
lastModifiedBy lastModifiedBy The ID of the person who made the last update to the busi
ness unit entry
Navigation Properties
Table 161:
Navigation Property Navigation Target Comments
headOfUnitNav User
nameTranslationNav
descriptionTranslationNav
statusNav MDFEnumValue
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/FOBusinessUnit?$format=json&$select=externalCode&
$top=3
Response
Sample Code
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://<localhost:port>/odata/v2/
FOBusinessUnit(externalCode='BU1',startDate=datetime'1970-01-01T00:00:00')",
"type" : "SFOData.FOBusinessUnit"
}, "externalCode" : "BU1"
}, {
"__metadata" : {
"uri" : "https://<localhost:port>/odata/v2/
FOBusinessUnit(externalCode='BU2',startDate=datetime'2013-12-12T00:00:00')",
"type" : "SFOData.FOBusinessUnit"
}, "externalCode" : "BU2"
}, {
"__metadata" : {
"uri" : "https://<localhost:port>/odata/v2/
FOBusinessUnit(externalCode='BU3',startDate=datetime'1970-01-01T00:00:00')",
"type" : "SFOData.FOBusinessUnit"
}, "externalCode" : "BU3"
}
]
}
}
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Payload { "__metadata":
{ "uri":"FOBusinessUnit(startDate=datetime'2014-09-11T00:00:00',externalCode='20000')" },
"status":"A" }
Response
Sample Code
<d:editStatus>UPSERTED</d:editStatus>
<d:message
m:null="true" />
<d:index
m:type="Edm.Int32">0</d:index>
<d:httpCode
m:type="Edm.Int32">200</d:httpCode>
<d:inlineResults
m:type="Bag(SFOData.UpsertResult)" />
</m:properties>
</content>
</entry>
</feed>
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
8.14.7 FOCostCenter
Operations Allowed
Operation Description
Object Information
Properties
The table below provides the mapping between attributes in OData and ODefinition fields. For more info about the
object definition fields, see the Data Object Tables for Cost Center in the Employee Central Master.
Table 162:
Property Name in OData Corresponding Field in Object Definition Comments
glStatementCode glStatementCode
costcenterManager costCenterManager
costcenterExternalObjectID costCenterExternalObjectId
Note
Element Type Map for EC Migration includes custom fields also.
Navigation Properties
We do not have any standard navigation from cost center. However, it is possible for customers to define
navigation. Once they do it, they can use the mapping objects to determine that these navigations must behave as
they did previously or in a particular way in the future.
Table 163:
Navigation Property Navigation Target Comments
Use Cases
Operation Query
Request http:///<localhost:port>/odata/v2/FOCostCenter&$format=json
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
{
"d": {
"results": [{
"__metadata": {
"uri": "https://localhost:443/odata/v2/
FOCostCenter(externalCode='aaaa',startDate=datetime'2014-04-22T00:00:00')",
"type": "SFOData.FOCostCenter"
Note
Any custom navigations and fields added after migration without any mapping maintained by the customer will
be returned as cust_<type><number>. For example, cust_string1Nav. For existing ones with mapping, the field
and navigation will be returned as –is. For example, customString1.
Operation Post
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Payload { "__metadata":
{ "uri":"FOCostCenter(startDate=datetime'2014-09-11T00:00:00',externalCode='20000')" },
"status":"A" }
Response
Request http://<localhost:port>/odata/v2/FOCostCenter?$select=externalCode
Content-Type: application/json;charset=utf-8
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
8.14.8 FOCompany
Operations Allowed
Operation Description
Object Information
MDF Object:LegalEntity
Business Keys: externalCode + startDate
Effective-date:true
The table below provides the mapping between attributes in OData and ODefinition fields. For more information
about the object definition fields, see the Data Object Tables for Business Unit in the Employee Central Master.
Table 164:
Property Corresponding Field in Ob Comments
ject Definition
country countryOfRegistration The name of the country where the company is located
defaultPayGroup defaultPayGroup The pay group that applies to employees in the company
standardHours standardWeeklyHours The number of hours employees are expected to work at the
company
createdOn createdDate The date that the company information was added
createdDateTime createdDate
createdBy createdBy The ID of the person who created the company entry
lastModifiedOn lastModifiedDate The date that the company information was modified
lastModifiedDateTime
lastModifiedBy lastModifiedBy The ID of the person who made the last update to the com
pany entry
Navigation Properties
Table 165:
Navigation Property Navigation Target Comments
toLegalEntityUSA LegalEntityUSA
toLegalEntityFRA LegalEntityFRA
toLegalEntityARG LegalEntityARG
toLegalEntityESP LegalEntityESP
toLegalEntityDEU LegalEntityDEU
defaultPayGroupNav FOPayGroup
countryNav Territory
defaultLocationNav FOLocation
countryOfRegistrationNav Country
statusNav MDFEnumValue
currencyNav Currency
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/FOCompany?$format=json&$select=externalCode&$top=3
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://localhost:443/odata/v2/
FOCompany(effectiveStartDate=datetime'2010-01-01T00:00:00',externalCode='ACE_CHN')
",
"type": "SFOData.FOCompany"
},
"externalCode": "ACE_CHN"
}, {
"__metadata": {
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Payload { "__metadata":
{ "uri":"FOCompany(startDate=datetime'2014-09-11T00:00:00',externalCode='20000')" }, "status":"A" }
Response
Sample Code
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
8.14.9 FODepartment
Operations Allowed
Operation Description
Object Information
MDF Object:Department
Business Keys: externalCode + startDate
Effective-date:true
Table 166:
Property Corresponding Field in Ob Comments
ject Definition
createdOn createdDate The date that the department information was added
createdDateTime createdDate
createdBy createdBy The ID of the person who created the department entry
lastModifiedOn lastModifiedDate The date that the department information was modified
lastModifiedDateTime
lastModifiedBy lastModifiedBy The ID of the person who made the last update to the depart
ment entry
Navigation Properties
Table 167:
Navigation Property Navigation Target Comments
costCenterNav FOCostCenter
nameTranslationNav
descriptionTranslationNav
statusNav MDFEnumValue
Use Cases
‹‹ If necessary, add any supplementary information about the use cases here ››
Operation Query
Request https://<localhost:port>/odata/v2/FODepartment?$format=json&$select=externalCode&
$top=3
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://<localhost:port>/odata/v2/
FODepartment(externalCode='Dept 1',startDate=datetime'2015-03-11T00:00:00')",
"type": "SFOData.FODepartment"
},
"externalCode": "Dept 1"
}, {
"__metadata": {
"uri": "https://<localhost:port>/odata/v2/
FODepartment(externalCode='Dept 3',startDate=datetime'2013-09-24T00:00:00')",
"type": "SFOData.FODepartment"
},
"externalCode": "Dept 3"
}, {
"__metadata": {
"uri": "https://<localhost:port>/odata/v2/
FODepartment(externalCode='ADBE-Eng',startDate=datetime'2014-03-26T00:00:00')",
"type": "SFOData.FODepartment"
},
"externalCode": "ADBE-Eng"
}]
}
}
Operation Post
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Payload { "__metadata":
{ "uri":"FODepartment(startDate=datetime'2014-09-11T00:00:00',externalCode='20000')" },
"status":"A" }
Response
Sample Code
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
8.14.10 FODivision
Operation Description
Object Information
MDF Object:Division
Business Keys: externalCode + startDate
Effective-date:true
Properties
Table 168:
Property Corresponding Field in Ob Comments
ject Definition
createdOn createdDate The date that the division information was added
createdDateTime createdDate
createdBy createdBy The ID of the person who created the division entry
lastModifiedOn lastModifiedDate The date that the division information was modified
lastModifiedDateTime
lastModifiedBy lastModifiedBy The ID of the person who made the last update to the division
entry
Navigation Properties
Table 169:
Navigation Property Navigation Target Comments
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
statusNav MDFEnumValue
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/FODivision?$format=json&$select=externalCode&$top=3
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://<localhost:port>/odata/v2/
FODivision(externalCode='Div 1',startDate=datetime'1970-01-01T00:00:00')",
"type": "SFOData.FODivision"
},
"externalCode": "Div 1"
}, {
"__metadata": {
"uri": "https://<localhost:port>/odata/v2/
FODivision(externalCode='Div 2',startDate=datetime'2013-11-04T00:00:00')",
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Response
Sample Code
Error Codes
The table below lists different error codes generated when using this API.
8.14.11 FOLegalEntityLocal<Country>
This chapter covers several entities containing country-specific fields of legal entities. The country identifier in the
entity name is the country ISO Code. For example, for Germany, the name of this entity will be
FOLegalEntityLocalDEU.
These entities are made available for backward-compatibility reasons only. For a particular country, the
corresponding entity exists if the following pre-requisites are fulfilled:
● There is an MDF object modeled that holds the country-specific legal entity fields for this country.
● The API Visibility of the entity is different from Not Visible.
● The element type map contains information, which indicates that the backward-compatible entity should be
offered for this country.
By default, five such country-specific entities are pre-shipped. These are FOLegalEntityLocalARG,
FOLegalEntityLocalDEU, FOLegalEntityLocalFRA, FOLegalEntityLocalESP, and FOLegalEntityLocalUSA.
Operations Allowed
Operation Description
Object Information
MDF Object:LegalEntity<Country>
Business Keys: externalCode + startDate + country
Effective-date:true
Table 170:
Property Corresponding Field in Ob Comments
ject Definition
externalCode externalCode The external code of the corresponding legal entity for which
the country-specific fields are maintained
country The country to which the local legal entity applies. This must
be the same as the entity type and the same as the country of
the corresponding legal entity.
createdOn createdDate The date that the local legal entity information was added
createdBy createdBy The ID of the person who created the local legal entity entry
lastModifiedOn lastModifiedDate The date that the local legal entity information was modified
lastModifiedBy lastModifiedBy The ID of the person who made the last update to the local le
gal entity entry
Navigation Properties
Table 171:
Navigation Property Navigation Target
countryNav Territory
genericNumber1Nav PicklistOption
legalEntityTypeNav PickListValueV2
The country-specific properties for the five pre-shipped countries are listed below.
For Argentina:
genericString1 cuitCode
For Germany:
genericString1 taxUnit
genericString2 socialAccidentInsurance
genericString3 socialAccidentInsuranceRegistrationNu
mber
For Spain:
genericString1 certificadoDeIdentificacionFiscal
For France:
genericNumber1 nafCode
genericNumber2 sirenCode
For USA:
genericString1 federalReserveBankID
genericString2 fedReserveBankDistrict
genericString3 employerID
genericString4 eeoCompanyCode
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/FOLegalEntityLocalCAN?$format=json&
$select=externalCode&$top=3
Response
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://<localhost:port>/odata/v2/
FOLegalEntityLocalCAN(country='CAN',externalCode='comTest2',startDate=datetime'201
3-12-02T00:00:00')",
"type": "SFOData.FOLegalEntityLocalCAN"
},
"externalCode": "comTest2"
}, {
"__metadata": {
"uri": "https://<localhost:port>/odata/v2/
FOLegalEntityLocalCAN(country='CAN',externalCode='SF2',startDate=datetime'2014-05-
07T00:00:00')",
"type": "SFOData.FOLegalEntityLocalCAN"
},
"externalCode": "SF2"
}, {
"__metadata": {
"uri": "https://<localhost:port>/odata/v2/
FOLegalEntityLocalCAN(country='CAN',externalCode='ADOBEIND',startDate=datetime'201
5-02-11T00:00:00')",
"type": "SFOData.FOLegalEntityLocalCAN"
},
"externalCode": "ADOBEIND"
}]
}
}
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
8.14.12 LegalEntity<Country>
This chapter covers several entities containing country-specific fields of legal entities. The country identifier in the
entity name is the country ISO Code. For example, for USA, the name of this entity will be LegalEntityUSA. Five
such country-specific entities are pre-shipped. These are LegalEntityESP, LegalEntityARG, LegalEntityUSA,
LegalEntityDEU, and LegalEntityFRA.
Operations Allowed
Operation Description
Object information
MDF Object:LegalEntity<Country>
Business Keys:LegalEntity_effectiveStartDate, LegalEntity_externalCode, externalCode
Effective-date:true
Properties
Table 172:
Property Comments
LegalEntity_externalCode The external code of the corresponding legal entity for which the country-specific
fields are maintained
externalCode A number
createdDate The date that the legal entity information was added
createdDateTime
createdBy The ID of the person who created the legal entity entry
lastModifiedDate The date that the legal entity information was modified
lastModifiedDateTime
lastModifiedBy The ID of the person who made the last update to the legal entity entry
The country-specific properties for the five pre-shipped countries are listed below.
For Argentina:
cuitCode
For Germany:
taxUnit
socialAccidentInsurance
socialAccidentInsuranceRegistrationNumber
For Spain:
certificadoDeIdentificacionFiscal
For France:
nafCode
sirenCode
For USA:
legalEntityType
federalReserveBankID
fedReserveBankDistrict
employerID
eeoCompanyCode
Navigation Properties
For USA
Table 173:
Navigation Property Navigation Target Comments
legalEntityTypeNav PickListValueV2
cust_string6Nav PickListValueV2
cust_string7Nav PickListValueV2
cust_string8Nav PickListValueV2
LegalEntityUSAPermissionsNav LegalEntityUSAPermissions
cust_employerIDNav PickListValueV2
cust_fedReserveBankDistrictNav PickListValueV2
For Germany
cust_string6Nav PickListValueV2
cust_string7Nav PickListValueV2
cust_string8Nav PickListValueV2
LegalEntityDEUPermissionsNav LegalEntityDEUPermissions
For Argentina
cust_string6Nav PickListValueV2
cust_string7Nav PickListValueV2
cust_string8Nav PickListValueV2
LegalEntityARGPermissionsNav LegalEntityARGPermissions
For Spain
cust_string6Nav PickListValueV2
cust_string7Nav PickListValueV2
cust_string8Nav PickListValueV2
LegalEntityESPPermissionsNav LegalEntityESPPermissions
For France
cust_string6Nav PickListValueV2
cust_string7Nav PickListValueV2
cust_string8Nav PickListValueV2
LegalEntityFRAPermissionsNav LegalEntityFRAPermissions
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/LegalEntityUSA?$format=json
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://localhost:443/odata/v2/
LegalEntityUSA(LegalEntity_effectiveStartDate=datetime'1990-01-01T00:00:00',LegalE
ntity_externalCode='ACE_USA',externalCode=6596L)",
"type": "SFOData.LegalEntityUSA"
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Content-Type: application/json;charset=utf-8
Response
Sample Code
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
This chapter covers several entities containing country-specific fields of job classifications. The country identifier
in the entity name is the country ISO Code. For example, for Brazil, the name of this entity will be
FOJobClassLocalBRA.
These entities are made available for backward-compatibility reasons only. For a particular country, the
corresponding entity exists if the following pre-requisites are fulfilled:
● There is an MDF object modeled that holds the country-specific job classification fields for this country.
● The of the entity is different from Not Visible.
● The element type map contains information, which indicates that the backward-compatible entity should be
offered for this country.
Operations Allowed
Operation Description
Object Information
Properties
Table 174:
Property Corresponding Field in Ob Comments
ject Definition
country The country to which the local job classification applies. This
must match the entity type.
createdOn createdDate The date that the local job class information was added.
createdBy createdBy The ID of the person who created the local job class entry
lastModifiedOn lastModifiedDate The date that the local job class information was modified
lastModifiedBy lastModifiedBy The ID of the person who made the last update to the local job
classification entry
Navigation Properties
Table 175:
Navigation Property Navigation Target Comments
countryNav Territory
The country-specific properties for the seven pre-shipped countries are listed below.
For Australia:
genericString1 ascoCode
genericNumber1 occupationalCode
For Canada:
genericString1 occupationalClassification
For France:
genericString1 inseeCode
genericNumber2 employeeCategory
genericNumber1 occupationalCode
For USA:
genericString1 localJobTitle
For Brazil:
For Italy:
genericNumber1 inailCode
For USA
Table 176:
Navigation Property Navigation Target Comments
genericNumber1Nav PicklistOption
genericNumber2Nav PicklistOption
genericNumber3Nav PicklistOption
genericNumber4Nav PicklistOption
genericNumber5Nav PicklistOption
genericNumber6Nav PicklistOption
eeo1JobCategoryNav PickListValueV2
eeo4JobCategoryNav PickListValueV2
eeo5JobCategoryNav PickListValueV2
eeo6JobCategoryNav PickListValueV2
eeoJobGroupNav PickListValueV2
flsaStatusUSANav PickListValueV2
For Brazil
Table 177:
Navigation Property Navigation Target Comments
genericString1Nav PicklistOption
occupationalCodeNav PickListValueV2
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/FOJobClassLocalCAN?$format=json&
$select=externalCode&$top=3
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
{
"d": {
"results": [{
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOJobClassLocalCAN(country='CAN',externalCode='PS',startDate=datetime'2013-10-17T0
0:00:00')",
"type": "SFOData.FOJobClassLocalCAN"
},
"externalCode": "PS"
}, {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOJobClassLocalCAN(country='CAN',externalCode='ACC',startDate=datetime'2015-09-03T
00:00:00')",
"type": "SFOData.FOJobClassLocalCAN"
},
"externalCode": "ACC"
}, {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOJobClassLocalCAN(country='CAN',externalCode='JC1',startDate=datetime'2015-08-25T
00:00:00')",
"type": "SFOData.FOJobClassLocalCAN"
},
"externalCode": "JC1"
}]
}
}
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
Related Information
Operations Allowed
Operation Description
Object information
MDF Object:JobClassificationCountry
Business Keys:JobClassification_effectiveStartDate, JobClassification_externalCode,
country
Effective-date:true
Properties
Table 178:
Property Comments
JobClassification_externalCode
country
createdOn The date that the job classification country information was added
createdDateTime
createdBy The ID of the person who created the job classification country entry
lastModifiedOn The date that the job classification country information was modified
lastModifiedDateTime
lastModifiedBy The ID of the person who made the last update to thejob classification country en
try
Navigation Properties
Table 179:
Navigation Property Navigation Target Comments
effectiveStatusNav MDFEnumValue
country Country
JobClassificationCountryPermissions JobClassificationCountryPermissions
Nav
toJobClassificationAUS JobClassificationAUS
toJobClassificationBRA FOJobClassLocalBRA
toJobClassificationCAN FOJobClassLocalCAN
toJobClassificationFRA FOJobClassLocalFRA
toJobClassificationGBR FOJobClassLocalGBR
toJobClassificationITA FOJobClassLocalITA
toJobClassificationUSA FOJobClassLocalUSA
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/JobClassificationCountry?$format=json
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
Sample Code
{
"__metadata": {
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Response
Sample Code
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
Operations Allowed
Operation Description
Object Information
MDF Object:JobFunction
Business Keys: externalCode + startDate
Effective-date:true
Properties
Table 180:
Property Corresponding Field in Ob Comments
ject Definition
jobFamily
createdOn The date that the job function information was added
createdDateTime
createdBy The ID of the person who created the job function entry
lastModifiedOn The date that the job function information was modified
lastModifiedDateTime
lastModifiedBy The ID of the person who made the last update to the job
function entry
Navigation Properties
Table 181:
Navigation Property Navigation Target Comments
parentFunctionCodeNav FOJobFunction
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
jobFunctionTypeNav PickListValueV2
typeNav PicklistOption
statusNav MDFEnumValue
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/FOJobFunction?$format=json&$select=externalCode&
$top=3
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
{
"d": {
"results": [{
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOJobFunction(externalCode='JF Code 2',startDate=datetime'1970-01-01T00:00:00')",
"type": "SFOData.FOJobFunction"
},
"externalCode": "JF Code 2"
}, {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOJobFunction(externalCode='JF Code 3',startDate=datetime'2013-10-16T00:00:00')",
"type": "SFOData.FOJobFunction"
},
"externalCode": "JF Code 3"
}, {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOJobFunction(externalCode='test1',startDate=datetime'2013-07-10T00:00:00')",
"type": "SFOData.FOJobFunction"
},
"externalCode": "test1"
}]
}
}
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Payload { "__metadata":
{ "uri":"FOJobFunction(startDate=datetime'2014-09-11T00:00:00',externalCode='20000')" },
"status":"A" }
Response
Sample Code
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
8.14.16 FOJobCode
Operations Allowed
Operation Description
Before the migration, you could handle the translatable fields in two ways. You would do translations for Job Code
using Legacy Translations and FOTranslations. This is replaced with the MDF standard translation approach. Now
translatable fields are handled in the same way as translatable fields in other migrated objects. This means that
you have these additional fields such as name_en_US, name_en_GB, and so on in the object structure. To maintain
Important changes to FOJobCode – name, description and custom string fields in APIs
● Used locale to return data: During migration of Job Code Translations, the Corporate Locale will be used to
copy translations to the new persistency. While copying, the corporate language will be used to copy a default
translations into the translatable fields of FO Job Code (such as name, description or custom string). After
enabling the new translation feature, the SOAP and OData API will return those default values in the corporate
language while it returned the values in the language of the API user before activating the feature. In case this
corporate locale differs from the locale of the API user (can be seen in Employee Central UI through options for
this user), the result of the translatable fields could differ. To avoid this, ensure that corporate language and
API user language are the same before migrating or activing the new Job Code Translation feature in
Provisioning. This is described later below.
● Before the migration, every custom string field of type worker was regarded as translatable if legacy
translation was used. Thus, for every worker field, a navigation attribute was added leading to LocalizedData.
After the migration, navigation attribute is still available, but this will not lead to any instance data.
● Filters and sort on translation navigation: After switching to the new Job Code Translation, the OData API
will no longer support filter, and order by for the navigations of translatable fields in FO Job Code. Filter is still
supported for default translation in field name. This means queries such as /odata/v2/FOJobCode?
$filter=nameTranslatioNav/localizedDataTranslation+eq+'My Job Chode' will no longer be possible. Query
such as /odata/v2/FOJobCode?$filter=name+eq+'My Job Code'&$expand=nameTranslationNav will still
work.
● Custom user ID fields: If a custom string field was configured as of type user, the corresponding user ID was
added to the translation table. With the new feature enabled, this user ID will now be returned in the
corresponding field itself and is not available anymore in the translation table.
Important changes to LocalizedData – name, description and custom string fields in APIs
● Top, skip, orderby, and query without filter: After switching to the new Job Code Translation, the
LocalizedData Entity can be queried using simple filter (using eq or in). However, there is no support anymore
for query without filter or paging, and ordering or sorting. LocalizedData must be retrieved using the Job Code
query using expand and not queried directly.
● Shortcut access: Direct access to the LocalizedData without $filter such as odata/vs2/
LocalizedData(localizedDataCode=(‘TR:421:,localizedDataLocale=‘en_GB’) is not possible anymore. Use
odata/v2/LocalizedData?$filter=localizedDataCode+eq+’TR:421’+and+localizedDataLocale+eq+‘en_GB’)
instead or do a direct expand from FOJobCode entity.
● Changed business keys: LocalizedData will have a different code instead of TR:11. A number such as
34569811 originating from the new GOLocalizedData will be returned.
● Null-values for a translation: This happens if LocalizedData is not returned anymore by the OData API. This is
also true for expanded navigations in FOJobCode.
Additional Information
To minimize impact of change, ensure that the corporate language defined in Provisioning is the same as the API
language defined for the user before activating the Provisioning settings (migration).
FO Job Code has a navigation attribute localNavDEFLT going to FOJobClassLocalDEFLT. This target entity
FOJobClassLocalDEFLT does not contain any business field. Before the migration, if the object data was
inconsistent, this navigation would lead to instance data. This was the case if you imported JobClassLocal data
for countries, which were not configured, or if you removed countries from country-specific Corporate Data Model,
after data was created. This inconsistency is not there now. After the migration, the navigation and the target
entity are still made available for compatibility reasons, even though they do not return any data.
Object information
MDF Object:JobClassification
Business Keys: externalCode + startDate
Effective-date:true
Table 182:
Property Corresponding Field in Ob Comments
ject Definition
parentJobCode parentJobClassification The ID for the highest job code in the hierarchy
defaultJobLevel defaultJobLevel The external code of the job level picklist option
jobFamily
defaultEmployeeClass defaultEmployeeClass The external code of the employee class picklist option
defaultSupervisorLevel defaultSupervisorLevel The external code of the supervisor level picklist option
jobFunction jobFunction
createdOn createdDate The date that the job code information was added
createdDateTime
createdBy createdBy The ID of the person who created the job code entry
lastModifiedOn lastModifiedDate The date that the job code information was modified
lastModifiedDateTime
lastModifiedBy lastModifiedBy The ID of the person who made the last update to the job
code entry
Navigation Properties
Table 183:
Navigation Property Navigation Target Comments
parentJobCodeNav FOJobCode
gradeNav FOPayGrade
jobFunctionNav FOJobFunction
localNavDEFLT FOJobClassLocalDEFLT
localNav<Country> FOJobClassLocal<Country>
defaultEmployeeClassNav PickListValueV2
defaultJobLevelNav PickListValueV2
defaultSupervisorLevelNav PickListValueV2
employeeClassNav PicklistOption
isRegularNav PicklistOption
jobLevelNav PicklistOption
supervisorLevelNav PicklistOption
toJobClassificationCountryNav JobClassificationCountry
regularTemporaryNav PickListValueV2
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/FOJobCode?$format=json&$select=externalCode&$top=3
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOJobCode(externalCode='TestCodePD',startDate=datetime'2012-05-21T00:00:00')",
"type": "SFOData.FOJobCode"
},
"externalCode": "TestCodePD"
}, {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOJobCode(externalCode='sales',startDate=datetime'1970-01-01T00:00:00')",
"type": "SFOData.FOJobCode"
},
"externalCode": "sales"
}, {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOJobCode(externalCode='PS',startDate=datetime'2013-10-17T00:00:00')",
"type": "SFOData.FOJobCode"
},
"externalCode": "PS"
}]
}
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Payload { "__metadata":
{ "uri":"FOJobCode(startDate=datetime'2014-09-11T00:00:00',externalCode='20000')" }, "status":"A" }
Response
Sample Code
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
Operations Allowed
Operation Description
Object Information
MDF Object:PayGroup
Business Keys: externalCode + startDate
Effective-date:true
Properties
Table 184:
Property Corresponding Field in Ob Comments
ject Definition
payrollVendorId payrollVendorId The ID for an external contractor who processes the payroll
primaryContactID primaryContactID The ID for the main contact for the pay group
primaryContactEmail primaryContactEmail The email address for the main contact of the pay group
primaryContactName primaryContactName The name of the main contact of the pay group
secondaryContactID secondaryContactID The ID for the secondary contact for the pay group
secondaryContactEmail secondaryContactEmail The email address for the secondary contact of the pay group
secondaryContactName secondaryContactName The name of the secondary contact of the pay group
lag lag Indicates the number of pay periods that an employee is paid
in arrears
earliestChangeDate earliestChangeDate
weeksInPayPeriod weeksInPayPeriod Indicates how many weeks the pay period is for a pay group
dataDelimiter dataDelimiter Indicates if you use a period (.) or a comma (,) to separte
thousands
decimalPoint decimalPoint Indicates if a period (.) is used for the decimal point
createdOn createdDate The date that the pay group information was added
createdDateTime
createdBy The ID of the person who created the pay group entry
lastModifiedOn lastModifiedDate The date that the pay group information was modified
lastModifiedDateTime
lastModifiedBy lastModifiedBy The ID of the person who made the last update to the pay
group entry.
Navigation Properties
Table 185:
Navigation Property Navigation Target Comments
nameTranslationNav FoTranslation
descriptionTranslationNav FoTranslation
payFrequencyNav PicklistOption
paymentFrequencyNav PickListValueV2
statusNav MDFEnumValue
Operation Query
Request https://<localhost:port>/odata/v2/FOPayGroup?$format=json&$select=externalCode&
$top=3
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
Sample Code
{
"d": {
"results": [{
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOPayGroup(externalCode='SAP',startDate=datetime'2013-11-02T00:00:00')",
"type": "SFOData.FOPayGroup"
},
"externalCode": "SAP"
}, {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOPayGroup(externalCode='pG1',startDate=datetime'2013-09-02T00:00:00')",
"type": "SFOData.FOPayGroup"
},
"externalCode": "pG1"
}, {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
FOPayGroup(externalCode='PG1',startDate=datetime'2014-12-09T00:00:00')",
"type": "SFOData.FOPayGroup"
},
"externalCode": "PG1"
}]
}
}
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Response
Sample Code
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
This is a foundation object that describes a pay calendar for a particular pay group. This means it is the collection
of all pay periods referring to the same pay group.
Operations Allowed
Operation Description
Object information
MDF Object:PayCalendar
Business Keys: payGroup
Effective-date:false
Properties
Property Comments
createdOn The date that the pay calendar information was added
createdDateTime
createdBy The ID of the person who created the pay calendar entry
lastModifiedOn The date that the pay calendar information was modified
lastModifiedDateTime
lastModifiedBy The ID of the person who made the last update to the pay
calendar entry
payGroup The external code of the pay group that is common to all
associated pay periods
Table 186:
Navigation Property Navigation Target Comments
PayCalendarPermissionsNav PayCalendarPermissions
payGroupNav FOPayGroup
toPayPeriod PayPeriod
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/PayCalendar?$format=json
Here, localhost is the name of your host and port is usually 443 or left blank.
Response
Sample Code
{
"__metadata": {
"uri": "https://localhost:443/odata/v2/PayCalendar('APAC_GROUP')",
"type": "SFOData.PayCalendar"
},
"payGroup": "APAC_GROUP",
"mdfSystemEffectiveEndDate": "\/Date(253402214400000)\/",
"mdfSystemObjectType": "PayCalendar",
"mdfSystemVersionId": null,
"lastModifiedDateTime": "\/Date(1447049529000+0000)\/",
"mdfSystemTransactionSequence": "1",
"createdBy": "admin",
"mdfSystemRecordId": "B48CD96182B440348ECAE2439136091E",
"mdfSystemEntityId": "A2FF33F88E724BF386D5D225975D0F17",
"createdDateTime": "\/Date(1442990456000+0000)\/",
"lastModifiedBy": "admin",
"mdfSystemStatus": "A",
"lastModifiedDate": "\/Date(1447078329000)\/",
"mdfSystemEffectiveStartDate": "\/Date(-2208988800000)\/",
"lastModifiedDateWithTZ": "\/Date(1447049529000+0000)\/",
"createdDate": "\/Date(1443019256000)\/",
"mdfSystemRecordStatus": "N",
"payGroupNav": {
"__deferred": {
"uri": "https://localhost:443/odata/v2/PayCalendar('APAC_GROUP')/
payGroupNav"
}
},
"mdfSystemRecordStatusNav": {
"__deferred": {
"uri": "https://localhost:443/odata/v2/PayCalendar('APAC_GROUP')/
mdfSystemRecordStatusNav"
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Response
Sample Code
Error Codes
The table below lists different error codes generated when using this API.
8.14.19 PayPeriod
Operations Allowed
Operation Description
Object information
MDF Object:PayPeriod
Business Keys: PayCalendar_payGroup,externalCode
Effective-date:false
Properties
Property Comments
PayCalendar_payGroup The external code of the pay group for this pay period
createdOn The date that the pay period information was added
createdDateTime
createdBy The ID of the person who created the pay period entry
lastModifiedOn The date that the pay period information was modified
lastModifiedBy The ID of the person who made the last update to the pay
period entry
lastModifiedDateTime
offcycle
payCheckIssueDate
payPeriodBeginDate
payPeriodEndDate
processingRunId
runType
Navigation Properties
PayPeriodPermissionsNav PayPeriodPermissions
runTypeNav PickListValueV2
Use Cases
Operation Query
Request https://<localhost:port>/odata/v2/PayPeriod?$format=json
Here, localhost is the name of your host and port is usually 443 or left blank.
Sample Code
{
"__metadata": {
"uri": "https://localhost:443/odata/v2/
PayPeriod(PayCalendar_payGroup='APAC_GROUP',externalCode=6636L)",
"type": "SFOData.PayPeriod"
},
"PayCalendar_payGroup": "APAC_GROUP",
"externalCode": "6636",
"payPeriodBeginDate": "\/Date(946684800000)\/",
"mdfSystemEffectiveEndDate": "\/Date(253402214400000)\/",
"mdfSystemObjectType": "PayPeriod",
"mdfSystemVersionId": null,
"runType": "INC",
"offcycle": false,
"lastModifiedDateTime": "\/Date(1447049529000+0000)\/",
"mdfSystemTransactionSequence": "1",
"cust_string1": "b",
"mdfSystemRecordId": "1ACED403FA1E4132B37D839DBDB87FB7",
"createdBy": "admin",
"mdfSystemEntityId": "818F9E53B6654906BFCDA0E1BAA5F607",
"processingRunId": "1",
"createdDateTime": "\/Date(1442990456000+0000)\/",
"lastModifiedBy": "admin",
"mdfSystemStatus": "A",
"lastModifiedDate": "\/Date(1447078329000)\/",
"mdfSystemEffectiveStartDate": "\/Date(-2208988800000)\/",
"lastModifiedDateWithTZ": "\/Date(1447049529000+0000)\/",
"payPeriodEndDate": "\/Date(1609372800000)\/",
"payCheckIssueDate": null,
"createdDate": "\/Date(1443019256000)\/",
"mdfSystemRecordStatus": "N",
"runTypeNav": {
"__deferred": {
"uri": "https://localhost:443/odata/v2/
PayPeriod(PayCalendar_payGroup='APAC_GROUP',externalCode=6636L)/runTypeNav"
}
},
"mdfSystemRecordStatusNav": {
"__deferred": {
"uri": "https://localhost:443/odata/v2/
PayPeriod(PayCalendar_payGroup='APAC_GROUP',externalCode=6636L)/
mdfSystemRecordStatusNav"
}
},
"mdf{
"__metadata": {
"uri": "https://localhost:443/odata/v2/
PayPeriod(PayCalendar_payGroup='APAC_GROUP',externalCode=6636L)",
"type": "SFOData.PayPeriod"
},
"PayCalendar_payGroup": "APAC_GROUP",
"externalCode": "6636",
"payPeriodBeginDate": "\/Date(946684800000)\/",
"mdfSystemEffectiveEndDate": "\/Date(253402214400000)\/",
"mdfSystemObjectType": "PayPeriod",
"mdfSystemVersionId": null,
"runType": "INC",
"offcycle": false,
"lastModifiedDateTime": "\/Date(1447049529000+0000)\/",
"mdfSystemTransactionSequence": "1",
"cust_string1": "b",
"mdfSystemRecordId": "1ACED403FA1E4132B37D839DBDB87FB7",
"createdBy": "admin",
Operation Post
Request https://<localhost:port>/odata/v2/upsert
Here, localhost is the name of your host and port is usually 443 or left blank.
Content-Type: application/json;charset=utf-8
Response
Error Codes
The table below lists different error codes generated when using this API.
AFFECTED_EXTERNAL_CODE_ERROR This record cannot be saved since one or more records of this
Code have reported errors.
Global Benefits offers a simplified, one-stop shop Benefits administration tool for organizations spread across the
globe.
9.1 Benefit
This entity is used to create and configure benefits. It is used for reimbursements and allowances, such as medical
bills, higher education, and a company car.
Permissions
Table 187:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions for Benefit.
● Enable benefits.
Operations Allowed
Table 188:
Operation Description
Table 189:
Property Description
Navigation Properties
Table 190:
Navigation Property Related Entity Description
Use Cases
Table 191:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/Entity('Benefit')",
"type" : "SFOData.Entity"
}, "path" : "Benefit", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "benefitId",
"path" : "Benefit/benefitId", "picklistOptionId" : null, "required" : false,
"sortable" : true, "type" : {
"name" : "long", "path" : "long"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"effectiveStartDate", "path" : "Benefit/effectiveStartDate", "picklistOptionId" :
null, "required" : true, "sortable" : true, "type" : {
"name" : "datetime", "path" : "datetime"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}
]
}, "upsertable" : true, "name" : "Benefit", "updatable" : true, "deletable" : true,
"properties" : {
"results" : [
{
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"ageOfRetirement", "path" : "Benefit/ageOfRetirement", "picklistOptionId" : null,
"required" : false, "sortable" : true, "type" : {
"name" : "decimal", "path" : "decimal"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
9.2 BenefitClaimAccumulation
This enitity enables the accumulation of benefit claims sot they can be tracked within a defined cycle.
Permissions
Table 192:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions for claim accumulation.
● Enable Benefits
Operations Allowed
Table 193:
Operation Description
Properties
Table 194:
Property Description
Navigation Properties
Table 195:
Navigation Property Related Entity Description
Benefit Claim Accumulation benefitClaims Gets the Benefit Employee Claim details.
Use Cases
None.
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('BenefitClaimAccumulation')", "type" : "SFOData.Entity"
}, "path" : "BenefitClaimAccumulation", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "externalCode",
"path" : "BenefitClaimAccumulation/externalCode", "picklistOptionId" : null,
"required" : false, "sortable" : true, "type" : {
"name" : "long", "path" : "long"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}
]
}, "upsertable" : true, "name" : "BenefitClaimAccumulation", "updatable" : true,
"deletable" : true, "properties" : {
"results" : [
{
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"accumulatedAmount", "path" : "BenefitClaimAccumulation/accumulatedAmount",
"picklistOptionId" : null, "required" : true, "sortable" : true, "type" : {
"name" : "decimal", "path" : "decimal"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"balanceCarryForwardAmount", "path" : "BenefitClaimAccumulation/
balanceCarryForwardAmount", "picklistOptionId" : null, "required" : false,
"sortable" : true, "type" : {
"name" : "decimal", "path" : "decimal"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"benefitBalanceCarryForwardDetails", "path" : "BenefitClaimAccumulation/
benefitBalanceCarryForwardDetails", "picklistOptionId" : null, "required" : false,
"sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "benefitClaims",
"path" : "BenefitClaimAccumulation/benefitClaims", "picklistOptionId" : null,
"required" : false, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "benefitNav",
"path" : "BenefitClaimAccumulation/benefitNav", "picklistOptionId" : null,
"required" : true, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "claimWindowEnd",
"path" : "BenefitClaimAccumulation/claimWindowEnd", "picklistOptionId" : null,
"required" : true, "sortable" : true, "type" : {
"name" : "datetime", "path" : "datetime"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
9.3 BenefitCompanyCarAllowedModels
This entity is used to create values for differenct car models that are selected from the drop-down list in the
application.
Permissions
Table 196:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions Assign the rele
vant permissions for the car models.
● Enable Benefits
Operations Allowed
Table 197:
Operation Description
Properties
Table 198:
Property Description
Navigation Properties
Table 199:
Navigation Property Related Entity Description
Use Cases
None.
This entity is used to create values for car lease service providers.
Permissions
Table 200:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions for car service provider.
● Enable Benefits
Operations Allowed
Table 201:
Operation Description
Properties
Table 202:
Property Description
effectiveStartDate The effective start date of the car lease from the service provider.
emiInterestRate The interest rate from the service provider for the equated monthly installments.
Table 203:
Navigation Property Related Entity Description
Use Cases
None.
9.5 BenefitCompanyCarRecommendedVendors
This entity stores the details of recommended vendors for the company car benefit.
Permissions
Table 204:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign relevant
permissions.
● Enable Benefits
Operations Allowed
Table 205:
Operation Description
Table 206:
Property Description
Navigation Properties
Table 207:
Navigation Property Related Entity Description
Use Cases
Table 208:
API Call Description
9.6 BenefitContact
This entity stores the contact details of persons who are responsible for providing benefit-related information.
Permissions
Table 209:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions.
● Enable Benefits
Operations Allowed
Table 210:
Operation Description
Properties
Table 211:
Property Description
Navigation Properties
None.
Use Cases
Table 212:
API Call Description
Entity Metadata
9.7 BenefitDocuments
This enity is used to store all kinds of documents related to the benefits, including policy documents, forms, and
relevant web links..
Permissions
Table 213:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign relevant
permissions.
Enable Benefits
Table 214:
Operation Description
Properties
Table 215:
Property Description
Navigation Properties
None.
Use Cases
Table 216:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('BenefitDocuments')", "type" : "SFOData.Entity"
}, "path" : "BenefitDocuments", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
9.8 BenefitEmployeeClaim
This entity stores the details of the claim transactions made by the employees for the various benefits in the
company.
Permissions
Table 217:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions.
● Enable Benefits
Operations Allowed
Table 218:
Operation Description
Table 219:
Property Description
benefitDataSourceWithExternalCode The list of benefits that the employee is eligible to claim for
Navigation Properties
Table 220:
Navigation Property Related Entity Description
Use Cases
Table 221:
API Call Description
Entity Metadata
{
"d" : {
9.9 BenefitEnrollment
This entity contains a list of all the benefits for which an Employee is eligible.An employee uses this object to enroll
for eligible benefits.
Table 222:
Permission System Required Setting
Role-based ● Only the eligible employees can create a benefit enrollment for the eligible benefits
● An administrator cannot do this unless he or she uses the proxy feature
● RBP can be enabled for this entity via Admin Tools
Go to Admin Tools Configure Object Definition Secured . Select Yes and set the category
as Miscellaneous Permissions .
Go to Admin Tools Manage Permission Roles Miscellaneous Permissions Assign the rele
vant permissions.
● Enable Benefits
Operations Allowed
Table 223:
Operation Description
Properties
Table 224:
Property Description
Table 225:
Navigation Property Related Entity Description
Use Cases
Table 226:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('BenefitEnrollment')", "type" : "SFOData.Entity"
}, "path" : "BenefitEnrollment", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"effectiveStartDate", "path" : "BenefitEnrollment/effectiveStartDate",
"picklistOptionId" : null, "required" : true, "sortable" : true, "type" : {
"name" : "datetime", "path" : "datetime"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "id", "path" :
"BenefitEnrollment/id", "picklistOptionId" : null, "required" : false, "sortable" :
true, "type" : {
"name" : "long", "path" : "long"
}, "updateable" : true, "upsertable" : true, "viewable" : true
This entity contains information about all the exceptions that occur if the enrollment amount does not match the
eligiblility criteria or if the enrollment period has expired.
Permissions
Table 227:
Permission System Required Setting
Go to Admin Tools Configure Object Definition Secured Yes . Set the category as
Miscellaneous permissions.
● Enable Benefits
Operations Allowed
Table 228:
Operation Description
Properties
Table 229:
Property Description
Table 230:
Navigation Property Related Entity Description
Use Cases
Table 231:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('BenefitsException')", "type" : "SFOData.Entity"
}, "path" : "BenefitsException", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "exceptionId",
"path" : "BenefitsException/exceptionId", "picklistOptionId" : null, "required" :
false, "sortable" : true, "type" : {
"name" : "long", "path" : "long"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}
]
}, "upsertable" : true, "name" : "BenefitsException", "updatable" : true,
"deletable" : true, "properties" : {
"results" : [
{
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"benefitExceptionDetails", "path" : "BenefitsException/benefitExceptionDetails",
"picklistOptionId" : null, "required" : false, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
9.11 BenefitInsurancePlan
This entity fetches the employee insurance plan details such as plan name, insurance provider, pay component,
coverage option and so on. This entity is available under Create Benefit portlet
Business Fields
● effectiveStartDate
● id
Required Fields
● frequency
● planName_en_US
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsurancePlan?$format=json&$top=1
Response
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsurancePlan(effectiveStartDate=datetime'2015-03-05T00:00:00',id=2664L)",
"type": "SFOData.BenefitInsurancePlan"
},
"id": "2664",
"effectiveStartDate": "/Date(1425513600000)/",
"planName_pt_BR": null,
Related Information
9.12 BenefitInsurancePlanEnrollmentDetails
Business Fields
● BenefitEnrollment_effectiveStartDate
● BenefitEnrollment_id
● externalCode
Required Fields
● BenefitEnrollment_effectiveStartDate
● BenefitEnrollment_id
● smoking
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/BenefitInsurancePlanEnroll
mentDetails?$format=json&$top=1
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsurancePlanEnrollmentDetails(BenefitEnrollment_effectiveStartDate=datetim
e'2015-05-26T00:00:00',BenefitEnrollment_id=4413L,externalCode=4414L)",
"type": "SFOData.BenefitInsurancePlanEnrollmentDetails"
},
"BenefitEnrollment_id": "4413",
"BenefitEnrollment_effectiveStartDate": "/Date(1432598400000)/",
"externalCode": "4414",
"enrolleeOptions": "4346",
"mdfSystemLastModifiedDate": "/Date(1432611313000)/",
"mdfSystemEffectiveEndDate": "/Date(253402214400000)/",
"mdfSystemObjectType": "BenefitInsurancePlanEnrollmentDetails",
"mdfSystemVersionId": null,
"mdfSystemLastModifiedDateWithTZ": "/Date(1432625713000+0000)/",
"lastModifiedDateTime": "/Date(1432625713000+0000)/",
"mdfSystemTransactionSequence": "1",
"benefitSalaryAmount": null,
"mdfSystemRecordId": "54E4E9506A884B61B630CDE5CD479F03",
"smoking": null,
"mdfSystemEntityId": "CE79BDBC8C9A4CB5B669C3E38B657C80",
"mdfSystemStatus": "A",
"roundedCoverageAmount": null,
"mdfSystemLastModifiedBy": "pchopra1",
"mdfSystemCreatedBy": "pchopra1",
"mdfSystemRecordStatus": "N",
"provider": "4345",
"employeeContribution": "10",
"mdfSystemCreatedDate": "/Date(1432611313000)/",
"employerContribution": "90",
"plan": "4348",
"createdBy": "pchopra1",
"coverage": "4347",
"lastModifiedBy": "pchopra1",
"createdDateTime": "/Date(1432625713000+0000)/",
"mdfSystemEffectiveStartDate": "/Date(-2208988800000)/",
"planNav": {
"__deferred": {
"uri": "https://apisalesdemo4.successfactors.com:443/
odata/v2/
BenefitInsurancePlanEnrollmentDetails(BenefitEnrollment_effectiveStartDate=datetim
e'2015-05-26T00:00:00',BenefitEnrollment_id=4413L,externalCode=4414L)/planNav"
}
},
"enrolleeOptionsNav": {
"__deferred": {
"uri": "https://apisalesdemo4.successfactors.com:443/
odata/v2/
BenefitInsurancePlanEnrollmentDetails(BenefitEnrollment_effectiveStartDate=datetim
e'2015-05-26T00:00:00',BenefitEnrollment_id=4413L,externalCode=4414L)/
enrolleeOptionsNav"
}
},
"coverageNav": {
"__deferred": {
"uri": "https://apisalesdemo4.successfactors.com:443/
odata/v2/
Related Information
This entity fetches the employee’s insurance dependent details such as dependent option and dependent type.
This entity is available under Insurance Plan portlet.
Business Fields
● BenefitEnrollment_effectiveStartDate
● BenefitEnrollment_id
● BenefitInsurancePlanEnrollmentDetails_externalCode
● dependentName
Required Fields
● BenefitEnrollment_effectiveStartDate
● BenefitEnrollment_id
● BenefitInsurancePlanEnrollmentDetails_externalCode
● dependentName
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceDependentDetail?
$format=json&$top=1
Response
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceDependentDetail(BenefitEnrollment_effectiveStartDate=datetime'2016
-01-01T00:00:00',BenefitEnrollment_id=4441L,BenefitInsurancePlanEnrollmentDetails_
externalCode=4442L,dependentName='4240')",
"type": "SFOData.BenefitInsuranceDependentDetail"
},
"dependentName": "4240",
"BenefitInsurancePlanEnrollmentDetails_externalCode": "4442",
"BenefitEnrollment_id": "4441",
"BenefitEnrollment_effectiveStartDate": "/Date(1451606400000)/",
"dateOfBirth": null,
"mdfSystemLastModifiedDate": "/Date(1447579447000)/",
"mdfSystemObjectType": "BenefitInsuranceDependentDetail",
"mdfSystemEffectiveEndDate": "/Date(253402214400000)/",
"mdfSystemVersionId": null,
"mdfSystemLastModifiedDateWithTZ": "/Date(1447597447000+0000)/",
"lastModifiedDateTime": "/Date(1447597447000+0000)/",
"mdfSystemCreatedDate": "/Date(1447579447000)/",
"mdfSystemTransactionSequence": "1",
"relationShipType": "2",
Related Information
This entity fetches the employee insurance coverage such as coverage name and type . This entity is available
under Insurance Plan portlet.
It allows you to retrieve information about an employee’s coverage such as coverage name, type and so on..
Business Fields
● coverageid
Required Fields
● amount
● coverageName_en_US
● coverageType
● factor
● percentage
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceCoverage?$format=json&
$top=1
Response
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceCoverage(2663L)",
"type": "SFOData.BenefitInsuranceCoverage"
},
"coverageId": "2663",
"mdfSystemLastModifiedDate": "/Date(1443075312000)/",
"mdfSystemObjectType": "BenefitInsuranceCoverage",
"mdfSystemLastModifiedDateWithTZ": "/Date(1443089712000+0000)/",
"lastModifiedDateTime": "/Date(1443089712000+0000)/",
"coverageLevel": "Wordlwide Cover incl. Winter",
"amount": "15000",
"coverageName_nl_NL": null,
"mdfSystemRecordId": "B239102F458F42BCAB96F2C0D3D6234B",
"mdfSystemEntityId": "1BEB3323C16E4D7E91D8EEA976E27913",
"mdfSystemStatus": "A",
"coverageName_defaultValue": "Annual",
"coverageName_ja_JP": null,
"mdfSystemLastModifiedBy": "admin",
"coverageName_es_ES": null,
"mdfSystemRecordStatus": "N",
"coverageName_fr_FR": null,
"benefitSalaryCalculationRule": null,
"minimumCoverageAmount": null,
"coverageName_en_GB": null,
"coverageName_ko_KR": null,
"mdfSystemCreatedDate": "/Date(1425525775000)/",
"createdBy": "admin",
"maximumCoverageAmount": null,
"createdDateTime": "/Date(1425543775000+0000)/",
"lastModifiedBy": "admin",
"mdfSystemEffectiveStartDate": "/Date(-2208988800000)/",
"basePayComponentGroup": null,
"mdfSystemEffectiveEndDate": "/Date(253402214400000)/",
"mdfSystemVersionId": null,
9.15 BenefitInsuranceProvider
This entity fetches the e insurance provider details. This entity is available under Insurance Plan portlet
Business Fields
● providerId
Required Fields
● providerName
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceProvider?$format=json&
$top=1
Response
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceProvider(2661L)",
"type": "SFOData.BenefitInsuranceProvider"
},
"providerId": "2661",
"mdfSystemLastModifiedDate": "/Date(1425525515000)/",
"contactPhone": "+4487989000982",
"mdfSystemObjectType": "BenefitInsuranceProvider",
"mdfSystemEffectiveEndDate": "/Date(253402214400000)/",
"mdfSystemVersionId": null,
"contactEmail": "help@aig.com",
"mdfSystemLastModifiedDateWithTZ": "/Date(1425543515000+0000)/",
"lastModifiedDateTime": "/Date(1425543515000+0000)/",
"mdfSystemCreatedDate": "/Date(1425525504000)/",
"mdfSystemTransactionSequence": "1",
"mdfSystemRecordId": "43201A09918840F1B87D878FF128F94A",
"createdBy": "admin",
"providerName": "AIG",
"mdfSystemEntityId": "777611AD2B674B528C32082B9705AAA0",
"createdDateTime": "/Date(1425543504000+0000)/",
Related Information
9.16 BenefitInsuranceEnrolleeOptions
This entity fetches the employee enrollee options such as enrollee option name and dependent option. This entity
is available under Insurance Plan portlet.
Business Fields
● id
Required Fields
● enrolleeOptionsName
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceEnrolleeOptions?
$format=json&$top=1
Sample Code
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeOptions(2662L)", "type" :
"SFOData.BenefitInsuranceEnrolleeOptions"
}, "id" : "2662", "mdfSystemLastModifiedDate" : "\/Date(1425525745000)\/",
"mdfSystemObjectType" : "BenefitInsuranceEnrolleeOptions",
"mdfSystemEffectiveEndDate" : "\/Date(253402214400000)\/", "mdfSystemVersionId" :
null, "enrolleeOptionsName" : "Self+Family", "mdfSystemLastModifiedDateWithTZ" :
"\/Date(1425543745000+0000)\/", "lastModifiedDateTime" : "\/
Date(1425543745000+0000)\/", "mdfSystemCreatedDate" : "\/Date(1425525745000)\/",
"mdfSystemTransactionSequence" : "1", "dependentOption" : "Self+Family",
"mdfSystemRecordId" : "982370C227EC4F30857B4E75EE06E4C1", "createdBy" : "admin",
"mdfSystemEntityId" : "C13F8D8D493D4207B714C69E6BB7F2DF", "createdDateTime" : "\/
Date(1425543745000+0000)\/", "lastModifiedBy" : "admin", "mdfSystemStatus" : "A",
"mdfSystemEffectiveStartDate" : "\/Date(-2208988800000)\/",
"mdfSystemLastModifiedBy" : "admin", "mdfSystemRecordStatus" : "N",
"mdfSystemCreatedBy" : "admin", "mdfSystemRecordStatusNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeOptions(2662L)/mdfSystemRecordStatusNav"
}
}, "enrolleType" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeOptions(2662L)/enrolleType"
}
}, "dependentOptionNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeOptions(2662L)/dependentOptionNav"
}
}, "toCoverageOptions" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeOptions(2662L)/toCoverageOptions"
}
}, "mdfSystemStatusNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeOptions(2662L)/mdfSystemStatusNav"
}
}
}
]
}
}
Related Information
This entity fetches the rate chart details such as employee’s age, Insurance plan, factor, flat amount and per
dependent. This entity is available under Insurance Plan portlet.
Business Fields
● effectiveStartDate
● rateChartId
Required Fields
● effectiveStartDate
● factor
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceRateChart?$format=json&
$top=1
Response
Sample Code
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceRateChart(effectiveStartDate=datetime'2015-04-28T00:00:00',rateCha
rtId='C20')", "type" : "SFOData.BenefitInsuranceRateChart"
}, "effectiveStartDate" : "\/Date(1430179200000)\/", "rateChartId" : "C20",
"insurancePlan" : "3943", "mdfSystemLastModifiedDate" : "\/
Date(1438848870000)\/", "mdfSystemObjectType" : "BenefitInsuranceRateChart",
"mdfSystemEffectiveEndDate" : "\/Date(253402214400000)\/", "mdfSystemVersionId" :
null, "mdfSystemLastModifiedDateWithTZ" : "\/Date(1438863270000+0000)\/",
"lastModifiedDateTime" : "\/Date(1438863270000+0000)\/",
"mdfSystemTransactionSequence" : "1", "currency" : "BRL", "mdfSystemRecordId" :
"174CBED54BCF48818B758CD287B3589B", "ageAsOfYear" : null, "mdfSystemEntityId" :
"85F93890789240C2B49E905AC99727C4", "mdfSystemStatus" : "A",
"mdfSystemLastModifiedBy" : "admin", "mdfSystemRecordStatus" : "N",
"ageAsOfMonth" : null, "mdfSystemCreatedBy" : "admin", "provider" : "3083",
"factor" : "-1", "mdfSystemCreatedDate" : "\/Date(1430231715000)\/",
"createdBy" : "admin", "coverage" : "5789", "createdDateTime" : "\/
Date(1430246115000+0000)\/", "ageAsOfDay" : null, "lastModifiedBy" : "admin",
"coverageNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceRateChart(effectiveStartDate=datetime'2015-04-28T00:00:00',rateCha
rtId='C20')/coverageNav"
}
}, "rateChartEnrollee" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceRateChart(effectiveStartDate=datetime'2015-04-28T00:00:00',rateCha
rtId='C20')/rateChartEnrollee"
}
}, "ageAsOfMonthNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceRateChart(effectiveStartDate=datetime'2015-04-28T00:00:00',rateCha
rtId='C20')/ageAsOfMonthNav"
Related Information
This entity fetches the enrollee rate chart details. This entity is available under Insurance Rate Chart portlet.
Business Fields
● BenefitInsuranceRateChart_effectiveStartDate
● BenefitInsuranceRateChart_rateChartId
● externalCode
Required Fields
● BenefitInsuranceRateChart_effectiveStartDate
● BenefitInsuranceRateChart_rateChartId
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceRateChartEnrollee?
$format=json&$top=1
Response
Sample Code
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceRateChartEnrollee(BenefitInsuranceRateChart_effectiveStartDate=dat
etime'2015-03-05T00:00:00',BenefitInsuranceRateChart_rateChartId='Medical Plan
A',externalCode=2668L)", "type" : "SFOData.BenefitInsuranceRateChartEnrollee"
}, "BenefitInsuranceRateChart_rateChartId" : "Medical Plan A",
"BenefitInsuranceRateChart_effectiveStartDate" : "\/Date(1425513600000)\/",
"externalCode" : "2668", "ageTo" : "60", "mdfSystemLastModifiedDate" : "\/
Date(1425526156000)\/", "mdfSystemEffectiveEndDate" : "\/
Date(253402214400000)\/", "mdfSystemObjectType" :
"BenefitInsuranceRateChartEnrollee", "mdfSystemVersionId" : null,
"mdfSystemLastModifiedDateWithTZ" : "\/Date(1425544156000+0000)\/",
"lastModifiedDateTime" : "\/Date(1425544156000+0000)\/",
"mdfSystemTransactionSequence" : "1", "mdfSystemRecordId" :
"D6076F81CBB5405794DC71B639ADB04F", "mdfSystemEntityId" :
"F36C85DBD840482EA084AF17FE6DD8CF", "mdfSystemStatus" : "A",
"benefitInsuranceEnrolleeType" : "2", "mdfSystemLastModifiedBy" : "admin",
"mdfSystemCreatedBy" : "admin", "mdfSystemRecordStatus" : "N",
"employeeContribution" : "100", "mdfSystemCreatedDate" : "\/
Date(1425526156000)\/", "employerContribution" : "100", "createdBy" : "admin",
"ageFrom" : "10", "lastModifiedBy" : "admin", "createdDateTime" : "\/
Date(1425544156000+0000)\/", "mdfSystemEffectiveStartDate" : "\/
Date(-2208988800000)\/", "mdfSystemRecordStatusNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceRateChartEnrollee(BenefitInsuranceRateChart_effectiveStartDate=dat
etime'2015-03-05T00:00:00',BenefitInsuranceRateChart_rateChartId='Medical Plan
A',externalCode=2668L)/mdfSystemRecordStatusNav"
}
}, "mdfSystemStatusNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceRateChartEnrollee(BenefitInsuranceRateChart_effectiveStartDate=dat
etime'2015-03-05T00:00:00',BenefitInsuranceRateChart_rateChartId='Medical Plan
A',externalCode=2668L)/mdfSystemStatusNav"
Related Information
9.19 BenefitInsuranceRateChartFixedAmount
This entity fetches the insurance rate chart with fixed amount.
It allows you to retrieve information about insurance rate chart with fixed amount.
Business Fields
● BenefitInsuranceRateChart_effectiveStartDate
● BenefitInsuranceRateChart_rateChartId
● externalCode
Required Fields
● BenefitInsuranceRateChart_effectiveStartDate
● BenefitInsuranceRateChart_rateChartId
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceRateChartFixedAmount?
$format=json&$top=1
Response
Sample Code
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceRateChartFixedAmount(BenefitInsuranceRateChart_effectiveStartDate=
datetime'2015-03-05T00:00:00',BenefitInsuranceRateChart_rateChartId='Medical Plan
A',externalCode=2667L)", "type" : "SFOData.BenefitInsuranceRateChartFixedAmount"
9.20 BenefitInsuranceCoverageOptions
This entity fetches the employee’s insurance coverage options such coverage details and enrollment for details.
Coverage Details consists of coverage and rate chart information. Enrollment For consists of enrollee option name,
dependent option and dependent type. This entity is available under Insurance Plan portlet.
Business Fields
● BenefitInsurancePlan_effectiveStartDate
● BenefitInsurancePlan_id
● externalCode
Required Fields
● BenefitInsurancePlan_effectiveStartDate
● BenefitInsurancePlan_id
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceCoverageOptions?
$format=json&$top=1
Response
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceCoverageOptions(BenefitInsurancePlan_effectiveStartDate=datetime'201
5-03-05T00:00:00',BenefitInsurancePlan_id=2664L,externalCode=2665L)", "type" :
"SFOData.BenefitInsuranceCoverageOptions"
}, "BenefitInsurancePlan_effectiveStartDate" : "\/Date(1425513600000)\/",
"externalCode" : "2665", "BenefitInsurancePlan_id" : "2664",
"mdfSystemLastModifiedDate" : "\/Date(1425527952000)\/", "enrolleeOptions" :
"2662", "mdfSystemObjectType" : "BenefitInsuranceCoverageOptions",
"mdfSystemEffectiveEndDate" : "\/Date(253402214400000)\/", "mdfSystemVersionId" :
null, "mdfSystemLastModifiedDateWithTZ" : "\/Date(1425545952000+0000)\/",
"lastModifiedDateTime" : "\/Date(1425545952000+0000)\/", "mdfSystemCreatedDate" :
"\/Date(1425525792000)\/", "mdfSystemTransactionSequence" : "1",
"mdfSystemRecordId" : "29309129560944A69F1786D1A6EA5270", "createdBy" : "admin",
"mdfSystemEntityId" : "FD498B65E0C44131969392EF503E5D42", "createdDateTime" : "\/
Date(1425543792000+0000)\/", "lastModifiedBy" : "admin", "mdfSystemStatus" : "A",
"mdfSystemEffectiveStartDate" : "\/Date(-2208988800000)\/",
"mdfSystemLastModifiedBy" : "admin", "mdfSystemRecordStatus" : "N",
"mdfSystemCreatedBy" : "admin", "enrolleeOptionsNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceCoverageOptions(BenefitInsurancePlan_effectiveStartDate=datetime'201
5-03-05T00:00:00',BenefitInsurancePlan_id=2664L,externalCode=2665L)/
enrolleeOptionsNav"
Related Information
9.21 BenefitInsuranceCoverageDetails
This entity fetches the employee insurance coverage details such as coverage and rate chart. This entity is
available under Insurance Plan portlet.
Business Fields
● mdfSystemEffectiveStartDate
Required Fields
● BenefitInsuranceCoverageOptions_externalCode
● BenefitInsurancePlan_effectiveStartDate
● BenefitInsurancePlan_id
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceCoverageDetails?
$format=json&$top=1
Response
{
"d" : {
Related Information
This entity fetches the employee insurance enrollee type details such as self, self+family, self+spouse. This entity
is available under Insurance Plan portlet.
Business Fields
● mdfSystemEffectiveStartDate
● relationShipType
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
Use Case:
Operation Query
URI http://<Hostname>/odata/v2/
BenefitInsuranceEnrolleeType?$format=json&
$top=1
Response
Sample Code
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeType(mdfSystemEffectiveStartDate=datetime'1900-01-01T00:00
:00',relationShipType='2')", "type" : "SFOData.BenefitInsuranceEnrolleeType"
}, "relationShipType" : "2", "mdfSystemEffectiveStartDate" : "\/
Date(-2208988800000)\/", "mdfSystemLastModifiedDate" : "\/Date(1425525722000)\/",
"mdfSystemEffectiveEndDate" : "\/Date(253402214400000)\/",
"mdfSystemObjectType" : "BenefitInsuranceEnrolleeType", "mdfSystemVersionId" :
null, "mdfSystemLastModifiedDateWithTZ" : "\/Date(1425543722000+0000)\/",
"lastModifiedDateTime" : "\/Date(1425543722000+0000)\/", "mdfSystemCreatedDate" :
"\/Date(1425525722000)\/", "mdfSystemTransactionSequence" : "1",
"mdfSystemRecordId" : "8B742C5C791745FEAB0481E464E48CEB", "createdBy" : "admin",
"mdfSystemEntityId" : "432103DBE8B64354A41EE26776B00996", "createdDateTime" : "\/
Date(1425543722000+0000)\/", "lastModifiedBy" : "admin", "mdfSystemStatus" : "A",
"mdfSystemLastModifiedBy" : "admin", "mdfSystemRecordStatus" : "N",
"mdfSystemCreatedBy" : "admin", "relationShipTypeNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeType(mdfSystemEffectiveStartDate=datetime'1900-01-01T00:00
:00',relationShipType='2')/relationShipTypeNav"
}
}, "mdfSystemRecordStatusNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeType(mdfSystemEffectiveStartDate=datetime'1900-01-01T00:00
:00',relationShipType='2')/mdfSystemRecordStatusNav"
}
}, "mdfSystemStatusNav" : {
"__deferred" : {
"uri" : "https://apisalesdemo4.successfactors.com:443/odata/v2/
BenefitInsuranceEnrolleeType(mdfSystemEffectiveStartDate=datetime'1900-01-01T00:00
:00',relationShipType='2')/mdfSystemStatusNav"
}
}
}
Related Information
9.23 BenefitProgramEnrollment
This entity contains the list of all of the benefit programs for which an employee is eligible.
Permissions
Table 256:
Permission System Required Setting
Role-based ● Only the Eligible Employee can create Benefit Enrollment for the eligible benefits.
● Adminstrators cannot do this unless he uses the proxy feature.
● RBP can be enabled for this MDF Object via admin tools.
Admin Tools Configure Object Definition Secured Yes Set category as Miscellaneous
permissions.
Admin Tools Manage Permission Roles Miscellaneous Permissions Assign the relevant
permissions.
● Enable Benefits
Operations Allowed
Table 257:
Operation Description
Table 258:
Property Description
benefitProgramDataSourceWithExternal The list of all benefit programs for which employee is eligible.
Code
effectiveEndDate The end date after which program enrollment is no longer active.
Navigation Properties
Table 259:
Navigation Property Related Entity Description
Benefit Program Enrollment BenefitProgramEnrollmentDetail This field contains the information for
benefit program enrollment.
Use Cases
Table 260:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('BenefitProgramEnrollment')", "type" : "SFOData.Entity"
}, "path" : "BenefitProgramEnrollment", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"effectiveStartDate", "path" : "BenefitProgramEnrollment/effectiveStartDate",
"picklistOptionId" : null, "required" : true, "sortable" : true, "type" : {
"name" : "datetime", "path" : "datetime"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
9.24 BenefitProgram
This entity is a bucket or pool that contains more than one benefit.
Table 261:
Permission System Required Setting
Role-based Go to Admin Tools Manage Permission Roles Miscellaneous Permissions . Assign the rele
vant permissions for BenefitProgram.
● Enable benefits
Operations Allowed
Table 262:
Operation Description
Properties
Table 263:
Property Description
Navigation Properties
Table 264:
Navigation Property Related Entity Description
Use Cases
Table 265:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/Entity('BenefitProgram')",
"type" : "SFOData.Entity"
}, "path" : "BenefitProgram", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"effectiveStartDate", "path" : "BenefitProgram/effectiveStartDate",
"picklistOptionId" : null, "required" : true, "sortable" : true, "type" : {
"name" : "datetime", "path" : "datetime"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "programId",
"path" : "BenefitProgram/programId", "picklistOptionId" : null, "required" : false,
"sortable" : true, "type" : {
"name" : "long", "path" : "long"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}
]
}, "upsertable" : true, "name" : "BenefitProgram", "updatable" : true,
"deletable" : true, "properties" : {
"results" : [
{
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "amount",
"path" : "BenefitProgram/amount", "picklistOptionId" : null, "required" : false,
"sortable" : true, "type" : {
"name" : "decimal", "path" : "decimal"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "benefits",
"path" : "BenefitProgram/benefits", "picklistOptionId" : null, "required" : false,
"sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : true, "upsertable" : true, "viewable" : true
This is used for defining a period (set of dates) within which a particular benefit and claim is available for
enrollment and elligible for an employee.
Permissions
Table 266:
Permission System Required Setting
● Enable Benefits
Operations Allowed
Table 267:
Operation Description
Properties
Table 268:
Property Description
balanceCarryForwardUptoDate The balance of a claim that is allowed to carry forward to a specific date.
Navigation Properties
None.
Use Cases
Table 269:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('BenefitSchedulePeriod')", "type" : "SFOData.Entity"
}, "path" : "BenefitSchedulePeriod", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "id", "path" :
"BenefitSchedulePeriod/id", "picklistOptionId" : null, "required" : false,
"sortable" : true, "type" : {
"name" : "long", "path" : "long"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}
]
}, "upsertable" : true, "name" : "BenefitSchedulePeriod", "updatable" : true,
"deletable" : true, "properties" : {
"results" : [
{
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" :
"balanceCarryForwardUptoDate", "path" : "BenefitSchedulePeriod/
balanceCarryForwardUptoDate", "picklistOptionId" : null, "required" : false,
"sortable" : true, "type" : {
"name" : "datetime", "path" : "datetime"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
9.26 BenefitSchedules
This entity is used for grouping two or more schedule periods. BenefitSchedules is required for allowances and
reimbursements. It defines the time period, by date, that an employee can enroll for and claim a benefit.
Table 270:
Permission System Required Setting
Role-based ● Only eligible employees can create Benefit Enrollment for eligible benefits.
● The administrator cannot do this unless he or she uses the proxy feature.
● RBP can be enabled for this entity via Admin Tools.
Go to Admin Tools Configure Object Definition Secured Yes Set the category as Mis
cellaneous permissions.
Admin Tools Manage Permission Roles Miscellaneous Permissions Assign the relevant
permissions.
● Enable Benefits
Operations Allowed
Table 271:
Operation Description
Properties
Table 272:
Property Description
None.
Use Cases
Table 273:
API Call Description
Entity Metadata
{
"d" : {
"__metadata" : {
"uri" : "https://qacand.successfactors.com:443/odata/v2/
Entity('BenefitSchedules')", "type" : "SFOData.Entity"
}, "path" : "BenefitSchedules", "insertable" : true, "keyProperties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "id", "path" :
"BenefitSchedules/id", "picklistOptionId" : null, "required" : false, "sortable" :
true, "type" : {
"name" : "long", "path" : "long"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}
]
}, "upsertable" : true, "name" : "BenefitSchedules", "updatable" : true,
"deletable" : true, "properties" : {
"results" : [
{
"businessKey" : true, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : true, "label" : null, "maxLength" : null, "name" : "id", "path" :
"BenefitSchedules/id", "picklistOptionId" : null, "required" : false, "sortable" :
true, "type" : {
"name" : "long", "path" : "long"
}, "updateable" : true, "upsertable" : true, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : false, "label" : null, "maxLength" : 255, "name" :
"mdfSystemCreatedBy", "path" : "BenefitSchedules/mdfSystemCreatedBy",
"picklistOptionId" : null, "required" : false, "sortable" : true, "type" : {
"name" : "string", "path" : "string"
}, "updateable" : false, "upsertable" : false, "viewable" : true
}, {
"businessKey" : false, "filterable" : true, "id" : false, "inlineRequired" : null,
"insertable" : false, "label" : null, "maxLength" : null, "name" :
"mdfSystemCreatedDate", "path" : "BenefitSchedules/mdfSystemCreatedDate",
"picklistOptionId" : null, "required" : false, "sortable" : true, "type" : {
"name" : "datetime", "path" : "datetime"
}, "updateable" : false, "upsertable" : false, "viewable" : true
}, {
In this section, you´ll find the APIs available for Payment Information.
Table 274:
You can use this entity to access the Payment Information Screen for South Africa (ZAF).
Operations Allowed
Table 275:
Operation Description
Properties
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Use Cases
Operation GET
URI http://<Hostname>/odata/v2/
PaymentInformationDetailV3ZAF?$format=json
Response
Sample Code
Operation Query
URI http://<Hostname>/odata/v2/
PaymentInformationDetailV3?$format=json&
$EXPAND=PaymentInformationDetailV3ZAFMETHO
D: GET
Response
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://10.97.147.58:443/odata/v2/
PaymentInformationDetailV3(PaymentInformationV3_effectiveStartDate=datetime'2016-0
5-25T00:00:00',PaymentInformationV3_worker='ykumar',externalCode=6853L)",
"type": "SFOData.PaymentInformationDetailV3"
},
"PaymentInformationV3_effectiveStartDate": "/Date(1464134400000)/",
"PaymentInformationV3_worker": "ykumar",
"externalCode": "6853",
"percent": null,
"amount": "23",
"accountNumber": "2332323",
"bank": null,
"paySequence": "1",
"payType": "PAYROLL",
"iban": null,
"purpose": null,
"currency": "ZAR",
"businessIdentifierCode": null,
"bankCountry": "ZAF",
"customPayType": null,
"accountOwner": "kumar",
"routingNumber": "123456",
"paymentMethod": "05",
"toPaymentInformationDetailV3JPN": {
"__deferred": {
"uri": "https://10.97.147.58:443/odata/v2/
PaymentInformationDetailV3(PaymentInformationV3_effectiveStartDate=datetime'2016-0
5-25T00:00:00',PaymentInformationV3_worker='ykumar',externalCode=6853L)/
toPaymentInformationDetailV3JPN"
}
},
"toPaymentInformationDetailV3ISR": {
"__deferred": {
"uri": "https://10.97.147.58:443/odata/v2/
PaymentInformationDetailV3(PaymentInformationV3_effectiveStartDate=datetime'2016-0
5-25T00:00:00',PaymentInformationV3_worker='ykumar',externalCode=6853L)/
toPaymentInformationDetailV3ISR"
}
},
"toPaymentInformationDetailV3COL": {
"__deferred": {
Related Information
11.1 PerAddressDEFLT
Operations Allowed
Table 278:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 279:
Property Description
addressType The address types are Home, Mailing, Benefits, and Payroll.
operation
lastModifiedBy The ID of the person who made the last update to the address entry.
Navigation Properties
Table 280:
Navigation Property Related Entity Description
When you make a last modified query, take a look at how this entitiy behaves with $filter and lastModifiedOn:
Use Cases
Table 281:
API Call Description
Code Examples
Sample Code
{
d: {
results: [1 ]
0:
{
__metadata: {
uri: "https://localhost:port/odata/v2/public/
PerAddressDEFLT(addressType='business',personIdExternal='jtong1',startDate=datetim
e'1993-02-15T00:00:00') "
type: " SFOData.PerAddressDEFLT "}-
personIdExternal: " jtong1 "
state: " CA "
address1: " 1500 Fashion Island Blvd. "
address2: " Ste. 300 "
}-
-}
-}
Related Information
Operations Allowed
Table 282:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 283:
Property Description
operation
createdBy The ID of the person who created the email address entry.
lastModifiedBy The ID of the person who made the last update to the email address entry.
Navigation Properties
Table 284:
Navigation Property Related Entity Description
Use Cases
Table 285:
API Call Description
Code Examples
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://localhost:port/odata/v2/public/
PerPerson('mhoff1')",
"type": "SFOData.PerPerson"
},
"personIdExternal": "mhoff1",
"dateOfBirth": "/Date(-775008000000)/",
"personalInfoNav": {
"results": [
{
"__metadata": {
"uri": "https://localhost:port/odata/v2/public/
PerPersonal(personIdExternal='mhoff1',startDate=datetime'1990-01-01T00:00:00')",
"type": "SFOData.PerPersonal"
Related Information
11.3 PersonEmpTerminationInfo
In SAP SuccessFactors Employee Central, you can use PersonEmpTerminationInfo to expose the latest
termination date of an employee.
Operations Allowed
You query PersonEmpTerminationInfo via $expand from the PerPerson entity. You cannot query
PersonEmpTerminationInfo directly.
Properties
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json.
If you need to use the latest termination date for your processes, you can retrieve with $expand from PerPerson.
The latest termination date of an employee is represented by the field latestTerminationDate.
URI http://<Hostname>/odata/v2/PerPerson?
$format=json&
$expand=personEmpTerminationInfoNav &
$select= personEmpTerminationInfoNav&
$filter=personEmpTerminationInfoNav/
personIdExternal+eq+'admin'
Response
Response:
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<Hostname>/odata/v2/PerPerson('admin')",
"type": "SFOData.PerPerson"
},
"personEmpTerminationInfoNav": {
"__metadata": {
"uri": "https://<Hostname>/odata/v2/PersonEmpTerminationInfo('admin')",
"type": "SFOData.PersonEmpTerminationInfo"
},
"personIdExternal": "admin",
"activeEmploymentsCount": 1,
"latestTerminationDate": null
}
}
]
}
}
Additional Information
11.4 PerEmergencyContacts
Table 287:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 288:
Property Description
isEmergencyContact Indicates that the person is an emergency contact for the employee.
gender The gender of the emergency contact is Male, Female, Unknown or Undeclared.
isAddSameAsEmployee Indicates if the dependent has the same address as the employee.
operation
createdBy The ID of the person who created the email address entry.
lastModifiedBy The ID of the person who made the last update to the email address entry.
Navigation Properties
Table 289:
Navigation Property Related Entity Description
addressNavDEFLT HrisEmergencyContactAddressDEFLT
Use Cases
Table 290:
API Call Description
https://<hostname>.com/odata/v2/ Get all persons who have more than one emergency contact
PerEmergencyContacts?$filter=primaryFlag
ne 'Y'&
$select=personIdExternal,relationship&
$format=JSON
Code Examples
{
"d": {
"results": [
{
Related Information
11.5 PerGlobalInfo
Operations Allowed
Table 291:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 292:
Property Description
createdBy The ID of the person who created the global information entry.
lastModifiedBy The ID of the person who made the last update to the global information entry.
Navigation Properties
Table 293:
Navigation Property Related Entity Description
When you make a last modified query, take a look at how this entitiy behaves with $filter and lastModifiedOn:
Related Information
11.6 PerNationalId
Operations Allowed
Table 294:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Table 295:
Property Description
operation
createdBy The ID of the person who created the email address entry.
lastModifiedBy The ID of the person who made the last update to the email address entry.
Navigation Properties
Table 296:
Navigation Property Related Entity Description
countryNav Territory
personNav PerPerson
Table 297:
API Call Description
https://<hostname>.com/odata/v2/ Get all person whose nationalId is not Primary in the country
PerNationalId?$filter=isPrimary eq they are living in
'false'&
$select=personIdExternal,nationalId,countr
y&$format=JSON
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
PerNationalId(cardType='itin',country='USA',personIdExternal='vstokes1')",
"type": "SFOData.PerNationalId"
},
"personIdExternal": "vstokes1",
"country": "USA",
"nationalId": "48-98493057"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
PerNationalId(cardType='itin',country='USA',personIdExternal='wsown1')",
"type": "SFOData.PerNationalId"
},
"personIdExternal": "wsown1",
"country": "USA",
"nationalId": "47-49409408"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
PerNationalId(cardType='itin',country='USA',personIdExternal='smormony1')",
"type": "SFOData.PerNationalId"
},
"personIdExternal": "smormony1",
"country": "USA",
"nationalId": "45-34593835"
}
]
}
}
11.7 PerPerson
In SAP Success Factors Employee Central, you can use this entity to display information about an employee such
as date and place of birth, and date of death.
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json. Upsert is supported with an incremental purge
Take a look at the HRIS object information in this table here. If you need more information about these attributes,
you can refer to the links in Related Information below.
Use Cases
Take a look at PerPerson Upsert [page 569] for information on how you can use this entity to add a new
employee.
SecondaryAssignmentNav lets you know which employment contract is the primary one for replication scenarios.
You can see how to use it in Differentiating primary from secondary employment during concurrent employment
replication [page 587].
personEmpTerminationInfoNav lets you retrieve the latest employment date for an employee. You can see a
sample use case in the entity documentationPersonEmpTerminationInfo [page 474] personEmpTerminationInfo.
Although the PerPerson entity is created when the user entity is upserted, it remains hidden. It only becomes
visible when:
● It is explicitly upserted
● EmpEmployment has been upserted. For more information, seeEmpEmployment Upsert [page 570]
● Filters for including or excluding internal and external users are available. For more information, see Filtering
out external user data [page 574]
Related Information
11.7.1 generateNextPersonID
You use this entity to generate the next person ID assigned for a new hire, incrementing it as required.
Operations Allowed
Operation Description
Use Cases
The generated IDs are used in the entities User Entity (fields: username and userID), PerPerson Entity (field:
personIdExternal, UserID), Employment Entity (fields: personIdExternal and userID), Per* Entities (field:
personIdExternal), Emp* Entities (field: userID)
Operation Post
Response
{
"d" : {
"GenerateNextPersonIDResponse" : {
"personID" : "214"
}
}
}
When you generate more then one ID, use a $BATCH statement to avoid too many roundtrips. Please make sure
that the consumer uses the generated IDs in a unique way. Any unused numbers will create gaps since the API
generates the numbers in an incremental fashion.
Operation Post
Request http://<Hostname>/odata/v2/$batch
Host: <Hostname>
Content-Length: 668
Payload --batch_36522ad7-fc75-4b56-8c71-56071383e77b
Content-Type: multipart/mixed; boundary=changeset_1
--changeset_1
Content-Transfer-Encoding: binary
Content-Type: application/http
--changeset_1
Content-Transfer-Encoding: binary
Content-Type: application/http
--changeset_1
Content-Transfer-Encoding: binary
Content-Type: application/http
--changeset_1--
--batch_36522ad7-fc75-4b56-8c71-56071383e77b--
--batch_840c9610-df87-42ce-bd42-948f9e3f8e04
Content-Type: multipart/mixed; boundary=changeset_75c877a0-4c68-4b0e-af47-
b8bdb19c117b
--changeset_75c877a0-4c68-4b0e-af47-b8bdb19c117b
Content-Type: application/http
Content-Transfer-Encoding: binary
HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8
DataServiceVersion: 1.0
Content-Length: 314
--changeset_75c877a0-4c68-4b0e-af47-b8bdb19c117b
Content-Type: application/http
Content-Transfer-Encoding: binary
HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8
DataServiceVersion: 1.0
Content-Length: 314
--changeset_75c877a0-4c68-4b0e-af47-b8bdb19c117b
Content-Type: application/http
Content-Transfer-Encoding: binary
HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8
DataServiceVersion: 1.0
Content-Length: 314
--changeset_75c877a0-4c68-4b0e-af47-b8bdb19c117b--
--batch_840c9610-df87-42ce-bd42-948f9e3f8e04--
Related Information
Operations Allowed
Table 298:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 299:
Property Description
maritalStatus The marital status types are Married, Single, Divorced, Widow, Unknown, Cohabita
tion, Separated, Head of Household, Partnership, Cohabitation with Contract
(Netherlands), Cohabitation without Contract (Netherlands), and PACS (France).
visibleMinority Indicates if the employee is not one of the majority race in a giving population. Valid
in Canada.
communityBackground
gender The gender types are Male, Female, Unknown, and Undeclared.
suffix The suffix of the employee. The list of values comes from the pre-defined picklist
namesuffix.
firstNameAlt1 The employee's first name in alternate characters in the employee's native lan
guage.
lastNameAlt1 The employee's last name in alternate characters in the employee's native lan
guage.
middleNameAlt1 The employee's middle name in alternate characters in the employee's native lan
guage.
since The date that the marital status of the employee is valid.
isOverridden Enables a user to customize the format for the name of the employee.
certificateStartDate The start date of the certificate that confirms that the employee is challenged.
certificateEndDate The end date of the certificate that confirms that the employee is challenged.
lastModifiedBy The ID of the person who made the last update to the personal entry.
Navigation Properties
Table 300:
Navigation Property Related Entity Description
When you make a last modified query, take a look at how this entity behaves with $filter and
lastModifiedDateTime:
Use Cases
Table 301:
API Call Description
https://<hostname>/odata/v2/PerPersonal? : Get all Persons (First and Lastname) where first or last name
$filter=firstName like 'Ca%' or lastName starts with Ca
like 'Ca%'&$select=firstName,lastName&
$format=JSON
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
PerPersonal(personIdExternal='wcarver1',startDate=datetime'1990-01-01T00:00:00')",
"type": "SFOData.PerPersonal"
},
"lastName": "Carver",
"firstName": "William"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
PerPersonal(personIdExternal='mclements1',startDate=datetime'1990-01-01T00:00:00')",
"type": "SFOData.PerPersonal"
},
"lastName": "Carvalho",
"firstName": "Marcelo"
},
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/public/
PerPersonal(personIdExternal='ecarpenter1',startDate=datetime'1990-01-01T00:00:00')"
,
"type": "SFOData.PerPersonal"
},
"lastName": "Carpenter",
"firstName": "Elizabeth"
},
Good to know
You can also choose whether to include or exclude internal and external user data from these queries. You can do
this by using the filter described in Filtering out external user data [page 574].
Related Information
11.9 PerPersonRelationship
Operations Allowed
Table 302:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Table 303:
Property Description
relationshipType The relationship of the dependent to the employee. The types are Child, Stepchild,
Child of Domestic Partner, Spouse, Registered Partner, Divorced Spouse, Father,
Mother, Brother, Sister, Related Persons, and Domestic Partner.
isAddressSameAsPerson Indicates if the dependent has the same address as the employee.
createdBy The ID of the person who created the email address entry.
lastModifiedBy The ID of the person who made the last update to the email address entry.
endDate The date the dependent is no longer the legal responsibility of the employee.
When you make a last modified query, take a look at how this entitiy behaves with $filter and lastModifiedOn:
Table 304:
Navigation Property Related Entity Description
relNationalIdNav PerNationalId
Related Information
11.10 PerPhone
Operations Allowed
Table 305:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 306:
Property Description
phoneType The type of phone number. The types are Home, Business, Business1, Cell, Cell1,
and Fax.
operation
createdBy The ID of the person who created the phone number entry.
lastModifiedBy The ID of the person who made the last update to the phone number entry.
Navigation Properties
Table 307:
Navigation Property Related Entity Description
Table 308:
API Call Description
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
PerPhone(personIdExternal='cgrant1',phoneType='5847')",
"type": "SFOData.PerPhone"
},
"phoneNumber": "565-3345",
"personNav": {
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
PerPerson('cgrant1')",
"type": "SFOData.PerPerson"
},
"personalInfoNav": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
PerPersonal(personIdExternal='cgrant1',startDate=datetime'2014-10-30T00:00:00')",
"type": "SFOData.PerPersonal"
},
"lastName": "Grant-Miller3",
"firstName": "Carla"
}
]
}
}
}
]
}
}
Related Information
11.11 PerSocialAccount
Operations Allowed
Table 309:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 310:
Property Description
operation
createdOn The date that the instant messaging account was added.
createdBy The ID of the person who created the instant messaging account entry.
lastModifiedOn The date that the instant messaging account was modified.
lastModifiedBy The ID of the person who made the last update to the instant messaging account
entry.
Navigation Properties
Table 311:
Navigation Property Related Entity Description
Use Cases
Table 312:
API Call Description
https://<hostname>.com/odata/v2/ Get all social accounts which do not equal the domain 1764
PerSocialAccount?$filter=domain ne '1764' and 1765
and domain ne '1765'&
$select=domain,personIdExternal,imId&
$format=JSON
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
PerSocialAccount(domain='1762',personIdExternal='cgrant1')",
"type": "SFOData.PerSocialAccount"
},
"personIdExternal": "cgrant1",
"domain": "1762",
"imId": "carla123"
Related Information
11.12 PersonKey
You can use this entity to expose the person UUID for integration and import scenarios.
Operations Allowed
You query PersonKey via $expand from the User entity. You cannot query PersonKey directly.
Properties
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json.
In integration and import scenarios, you can use PersonKey to retrieve the person UUID represented by the field
perPersonUuid. This field is automatically populated by the system when a user is created. The value is immutable
meaning that you cannot change it.
URI http://<Hostname>/odata/v2/User('admin')?
$format=json&$expand=personKeyNav&
$filter=personKeyNav/pePersonUuid eq
"3A085DB0D9184B49B0E3E70D6F07EB1A"
Response
Sample Code
Extract from response
Response:
{
"d": {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/User('admin')",
"type": "SFOData.User"
},
....
},
"personKeyNav": {
"__metadata": {
"uri": "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
PersonKey('admin')",
"type": "SFOData.PersonKey"
},
"personIdExternal": "admin",
"personId": "2",
"perPersonUuid": "3A085DB0D9184B49B0E3E70D6F07EB1A"
}
Additional Information
User
Related Information
In this section, you'll find the APIs available for Time Off. You can use Time Off to manage absences such as
vacation, sick leave, and paid time off.
12.1.1 AccrualCalculationBase
The entity is used to store reported times (per user and date). The records need to be provided to this storage
from a data source outside Time Off, such as by import or integration using OData. The entity represents the raw
data.
Operations Allowed
Table 314:
Operation Description
Properties
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations.
Table 315:
Code Examples
URI: http://<hostname>/odata/v2/upsert
Accept: application/json
Content-Type: application/json;charset=utf-8
Payload
{
"__metadata" : {
"uri" : "http://localhost:8080/odata/v2/
AccrualCalculationBase(externalCode='country_2015-12-28')",
"type" : "SFOData.AccrualCalculationBase"
},
"externalCode" : "country_2015-12-28",
"userId" : "country",
"actualQuantity" : 6,
"date" : "\/Date(1451260800000)\/"
}
Response:
{
"d" : [
{
"key" : null,
"status" : "OK",
"editStatus" : "UPSERTED",
"message" : null,
"index" : 0,
"httpCode" : 200,
"inlineResults" : null
}
]
}
URI: http://<hostname>/odata/v2/AccrualCalculationBase?$format=json
Operation: GET
Response:
{
"d" : {
Contains information about the available time type, which is one of the time types that an employee is allowed to
take.
Operations Allowed
Table 316:
Operation Description
Properties
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations.
Table 317:
Code Examples
{
"d" : {
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/
AvailableTimeType(TimeTypeProfile_externalCode='Vacation CLT',externalCode='1')",
"type" : "SFOData.AvailableTimeType"
},
12.1.3 EmployeeTime
This entitiy contains information related to attendance times of hourly and salaried employees.
Operations Allowed
Table 318:
Operation Description
Properties
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations.
Table 319:
endDate No Yes
externalCode Yes No
startDate No Yes
Use Cases
Table 320:
API Call Description
https://<hostname>/odata/v2/EmployeeTime?& Get employee time for the user defined in the call.
$format=json&$filter=userId%20eq
%20'raji1505emp'
Code Examples
{
d: {
results: [104]
0: {
__metadata: {
uri: "https://sfapiqacand.sflab.ondemand.com:443/odata/v2/
EmployeeTime('50f007dd864e448691e8f2cf0ae5f0fe')"
type: "SFOData.EmployeeTime"
}-
externalCode: "50f007dd864e448691e8f2cf0ae5f0fe"
quantityInDays: null
mdfSystemObjectType: "EmployeeTime"
cancellationWorkflowRequestId: null
endDate: "/Date(1420416000000)/"
Country-specific entities for EmployeeTime are available. Take a look at the Properties section to see which
coutries are supported with country-specific fields. These entities are child entities of EmployeeTime.
Operations Allowed
Table 321:
Operation Description
Properties
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations. These
tables list the country-specific properties and these are in additon to the properties listed for the parent element
EmployeeTime.
EmployeeTimeDEU
This entity contains information about employee time created for sick leave. It is specific to Germany and is a child
of the entity EmployeeTime.
Table 322:
continuedPayCreditedDays No No
continuedPayEndDate No No
overlappingSicknessGroup No No
paySupplementEndDate No No
paySupplementStartDate No No
sicknessCertificateStartDate No No
EmployeeTimeESP
This entity contains information about employee time created for sick leave. It is specific to Spain and is a child of
the entity EmployeeTime.
Table 323:
identicalSicknessGroup No No
12.1.5 EmployeeTimeCalendar
Contains absence information on a daily basis. There is one entry for every working day with the relevant number
of days and number of hours. For example, if there is a half day absence on an eight-hour working day, the
resulting calendar entry has 0.5 days and 4 hours
Operations Allowed
Table 324:
Operation Description
Properties
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations.
OData Examples
Example – Retrieve data of the employee time calendar which belongs to the employee time with specific external
code
Example – Retrieve data of the employee time calendar which belongs to the employee time with specific external
code
URI http://<hostname>/odata/v2/
EmployeeTimeCalendar(EmployeeTime_externalCode='2b78b4b19d88473396cb889b7377bd86',externalCode='
863b810ca1c64457ad033b3f048879b0')?$format=json
Response
{
"d" : {
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/
EmployeeTimeCalendar(EmployeeTime_externalCode='2b78b4b19d88473396cb889b7377bd86',ex
ternalCode='863b810ca1c64457ad033b3f048879b0')", "type" :
"SFOData.EmployeeTimeCalendar"
},
"externalCode" : "863b810ca1c64457ad033b3f048879b0",
"EmployeeTime_externalCode" : "2b78b4b19d88473396cb889b7377bd86",
"quantityInDays" : "1",
12.1.6 Holiday
You use the Holiday object to create holidays for inclusion in a holiday calendar.
Operations Allowed
Table 326:
Operation Description
Properties
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations.
Code Examples
http://<hostname>/odata/v2/Holiday?$format=json&$filter=holidayCode%20eq
%20'Christmas'
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/Holiday('Christmas')", "type" :
"SFOData.Holiday"
}, "holidayCode" : "Christmas", "mdfSystemEffectiveEndDate" : "\/
Date(253402214400000)\/", "mdfSystemObjectType" : "Holiday", "mdfSystemVersionId" :
null, "name_ru_RU" : null, "lastModifiedDateTime" : "\/Date(1420620519000+0000)\/",
"mdfSystemTransactionSequence" : "1", "mdfSystemRecordId" :
"CFF7BAFB4C2144AC8899EFD56BC9D344", "mdfSystemEntityId" :
"06BACE6B44ED4458AA40A837CA1896F5", "name_en_DEBUG" : null, "mdfSystemStatus" :
"A", "lastModifiedDateWithTZ" : "\/Date(1420620519000+0000)\/", "createdDate" : "\/
Date(1420624119000)\/", "name_defaultValue" : "Christmas",
"mdfSystemRecordStatus" : "N", "name_en_US" : "Christmas", "oldName" : null,
"country" : null, "createdBy" : "daily", "lastModifiedBy" : "daily",
"createdDateTime" : "\/Date(1420620519000+0000)\/", "mdfSystemEffectiveStartDate" :
"\/Date(-2208988800000)\/", "lastModifiedDate" : "\/Date(1420624119000)\/",
"name_en_GB" : null, "countryNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/Holiday('Christmas')/countryNav"
}
}, "mdfSystemRecordStatusNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/Holiday('Christmas')/
mdfSystemRecordStatusNav"
}
}, "mdfSystemStatusNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/Holiday('Christmas')/mdfSystemStatusNav"
}
}
}
]
}
}
Operations Allowed
Table 328:
Operation Description
Properties
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations.
Table 329:
Navigation Properties
Table 330:
Table 331:
http://<hostname>/odata/v2/HolidayCalendar?$for Get a holiday calendar for country defined in the call (Ger
mat=json&$filter=country%20eq%20'DEU' many) and in JSON format.
http://<hostname>/odata/v2/HolidayCalendar('HOLI Navigate from the holiday calendar with external code “HOLI
DAYS')/holidayAssignments DAYS” to the associated holiday assignments
Code Examples
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/HolidayCalendar('HOLIDAYS')", "type" :
"SFOData.HolidayCalendar"
}, "externalCode" : "HOLIDAYS", "mdfSystemEffectiveEndDate" : "\/
Date(253402214400000)\/", "mdfSystemObjectType" : "HolidayCalendar",
"mdfSystemVersionId" : null, "name_ru_RU" : null, "lastModifiedDateTime" : "\/
Date(1449580647000+0000)\/", "cust_ob" : null, "mdfSystemTransactionSequence" :
"1", "mdfSystemRecordId" : "98B44ABC06BE4C6FBB5282413BF14196", "name_en_DEBUG" :
null, "mdfSystemEntityId" : "E16F5376204240C9B62FBA0EB0994224", "mdfSystemStatus" :
"A", "lastModifiedDateWithTZ" : "\/Date(1449580647000+0000)\/",
"name_defaultValue" : "HOLIDAYS", "createdDate" : "\/Date(1428494651000)\/",
"mdfSystemRecordStatus" : "N", "name_en_US" : null, "oldName" : null, "country" :
"DEU", "createdBy" : "daily", "mdfSystemExternalUserVisibility" : null,
"lastModifiedBy" : "daily", "createdDateTime" : "\/Date(1428487451000+0000)\/",
"lastModifiedDate" : "\/Date(1449584247000)\/", "mdfSystemEffectiveStartDate" : "\/
Date(-2208988800000)\/", "name_en_GB" : "Holidays", "holidayAssignments" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/HolidayCalendar('HOLIDAYS')/
holidayAssignments"
}
}, "countryNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/HolidayCalendar('HOLIDAYS')/countryNav"
}
}, "mdfSystemExternalUserVisibilityNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/HolidayCalendar('HOLIDAYS')/
mdfSystemExternalUserVisibilityNav"
}
}, "mdfSystemRecordStatusNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/HolidayCalendar('HOLIDAYS')/
mdfSystemRecordStatusNav"
}
}, "mdfSystemStatusNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/HolidayCalendar('HOLIDAYS')/
mdfSystemStatusNav"
}
}
}
]
12.1.8 TimeAccount
When an employee has a time profile assigned with time types that refer to time account types, time accounts
need to be created. This is done automatically when you assign a time profile to an employee’s job information and
also during the account creation calendar run.
Operations Allowed
Table 332:
Operation Description
Major Navigations
● timeAccountDetails – Navigation to account bookings resulting from different scenarios like leave request
creation, calendar runs, or manual adjustments
Properties
Tip
We recommend that you do not use OData to create time accounts. Use the read scenario only.
Table 333:
Code Examples
Example: Retrieve data of the time accounts for user Country in JSON.
URI: http://<hostname>/odata/v2/TimeAccount?$filter=userId%20eq%20'country'&$format=json
Response:
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/
TimeAccount('1dfca28bf0c84c8b846719feffba225d')", "type" : "SFOData.TimeAccount"
},
"externalCode" : "1dfca28bf0c84c8b846719feffba225d",
"startDate" : "\/Date(1420070400000)\/",
"mdfSystemEffectiveEndDate" : "\/Date(253402214400000)\/", "mdfSystemObjectType" :
"TimeAccount",
"mdfSystemVersionId" : null,
"accountClosed" : false,
"endDate" : "\/Date(1451520000000)\/",
"lastModifiedDateTime" : "\/Date(1450708186000+0000)\/",
"mdfSystemTransactionSequence" : "1",
"mdfSystemRecordId" : "7A6A238F6FFA4D4C95A059D8069A9932",
"mdfSystemEntityId" : "C4114EE8D0A3425BB46ACF7D07A5D3D4",
"userId" : "country",
"mdfSystemStatus" : "A",
"lastModifiedDateWithTZ" : "\/Date(1450708186000+0000)\/",
"createdDate" : "\/Date(1440413096000)\/",
"mdfSystemRecordStatus" : "N",
"createdBy" : "daily",
"lastModifiedBy" : "daily", "createdDateTime" : "\/Date(1440405896000+0000)\/",
"bookingEndDate" : "\/Date(1451520000000)\/",
"accountType" : "VACATION CLT",
"lastModifiedDate" : "\/Date(1450711786000)\/",
"mdfSystemEffectiveStartDate" : "\/Date(-2208988800000)\/", "bookingStartDate" : "\/
Date(1420070400000)\/",
"timeAccountDetails" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/
TimeAccount('1dfca28bf0c84c8b846719feffba225d')/timeAccountDetails"
12.1.9 TimeAccountDetail
The entity describes account bookings resulting from different scenarios such as leave request creation or manual
adjustments.
Operations Allowed
Table 334:
Operation Description
Properties
Tip
We recommend that you use OData only to create Time Account Details with the “Manual Adjustment” booking
type. Use the read scenario only.
Code Examples
URI: http://<hostname>/odata/v2/upsert
Operation: POST
Content-Type: application/json;charset=utf-8
Payload:
{
"__metadata" : {
"uri" : "http://localhost:8080/odata/v2/
TimeAccountDetail(TimeAccount_externalCode='1dfca28bf0c84c8b846719feffba225d',
externalCode='MyTimeAccountDetail')",
"type" : "SFOData.TimeAccountDetail"
}, "TimeAccount_externalCode" : "1dfca28bf0c84c8b846719feffba225d",
"externalCode" : "MyTimeAccountDetail",
"bookingUnit" : "DAYS",
"referenceObject" : null,
"bookingType" : "MANUAL_ADJUSTMENT",
"bookingDate" : "\/Date(1420070400000)\/",
URI: http://localhost:8080/odata/v2/
TimeAccountDetail(TimeAccount_externalCode='1dfca28bf0c84c8b846719feffba225d',externalCode='62d7d936
18244c28922fdc4b94001e53')?$format=json
Operation: GET
Response:
{
"d" : {
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/
TimeAccountDetail(TimeAccount_externalCode='1dfca28bf0c84c8b846719feffba225d',extern
alCode='62d7d93618244c28922fdc4b94001e53')", "type" : "SFOData.TimeAccountDetail"
},
"TimeAccount_externalCode" : "1dfca28bf0c84c8b846719feffba225d",
"externalCode" : "62d7d93618244c28922fdc4b94001e53",
"mdfSystemEffectiveEndDate" : "\/Date(253402214400000)\/", "mdfSystemObjectType" :
"TimeAccountDetail",
"mdfSystemVersionId" : null,
"bookingUnit" : "DAYS",
"referenceObject" : null,
"bookingType" : "MANUAL_ADJUSTMENT",
"changeCalendar" : null,
"lastModifiedDateTime" : "\/Date(1440658227000+0000)\/",
"calendarEntry" : null,
"mdfSystemTransactionSequence" : "1",
"mdfSystemRecordId" : "5AF4FF7D85384DC1A5D86E4D3BB0931E",
"mdfSystemEntityId" : "F94ADC562C8E451DAD84E9DC24163256",
"mdfSystemStatus" : "A",
"lastModifiedDateWithTZ" : "\/Date(1440658227000+0000)\/",
"createdDate" : "\/Date(1440665427000)\/",
"mdfSystemRecordStatus" : "N",
"bookingDate" : "\/Date(1420070400000)\/",
"employeeTime" : null,
"accrualPeriodId" : null,
"createdBy" : "country",
"bookingAmount" : "2.0",
"createdDateTime" : "\/Date(1440658227000+0000)\/",
"lastModifiedBy" : "country",
"lastModifiedDate" : "\/Date(1440665427000)\/", "mdfSystemEffectiveStartDate" : "\/
Date(-2208988800000)\/",
"comment" : null, "employeeTimeNav" : {
"__deferred" : {
12.1.10 TimeAccountPostingRule
Time account posting rule associates a time type with a time account type to determine whether time accounts
should be managed for the time type. For example, you can use it to enable automatic checks against a balance
when time off is requested.
Operations Allowed
Table 336:
Operation Description
Table 337:
Code Example
Example – Retrieve data of the time account posting rule which belongs to the time type ’Vacation’
URI: http://<hostname>/odata/v2/
TimeAccountPostingRule(TimeType_externalCode='Vacation',externalCode='Annually_VAC')?$format=json
Response:
{
"d" : {
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/
TimeAccountPostingRule(TimeType_externalCode='Vacation',externalCode='Annually_VAC')
", "type" : "SFOData.TimeAccountPostingRule"
},
"TimeType_externalCode" : "Vacation",
"externalCode" : "Annually_VAC",
"mdfSystemEffectiveEndDate" : "\/Date(253402214400000)\/",
"mdfSystemObjectType" : "TimeAccountPostingRule",
"mdfSystemVersionId" : null,
"lastModifiedDateTime" : "\/Date(1422284110000+0000)\/",
"timeAccountType" : "ANNUALLY", "mdfSystemTransactionSequence" : "1", "createdBy" :
"loa",
"mdfSystemRecordId" : "877FE3EF357D4A4B825EF1C8EB0A675A",
"mdfSystemEntityId" : "3009BBBA98A14011A5DA5FC863C43B4F",
"createdDateTime" : "\/Date(1420710506000+0000)\/",
"lastModifiedBy" : "daily",
"mdfSystemStatus" : "A",
"lastModifiedDate" : "\/Date(1422287710000)\/", "mdfSystemEffectiveStartDate" : "\/
Date(-2208988800000)\/",
"lastModifiedDateWithTZ" : "\/Date(1422284110000+0000)\/",
"createdDate" : "\/Date(1420714106000)\/",
"mdfSystemRecordStatus" : "N",
"timeAccountTypeNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/
TimeAccountPostingRule(TimeType_externalCode='Vacation',externalCode='Annually_VAC')
/timeAccountTypeNav"
}
},
"mdfSystemRecordStatusNav" : {
"__deferred" : {
12.1.11 TimeAccountType
The entity is the template regulating what user-specific time accounts should look like.
Operations Allowed
Table 338:
Operation Description
Business Keys
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations.
Table 339:
externalName No Yes
accrualFrequency No No
accrualCreationAutomationLevel No Yes
accrualAutomationLevel No Yes
creation No Yes
accountCreationReferenceDate No No
simulateAccruals No Yes
pepCalendarAutomationLevel No Yes
payoutEligibility No No
payComponentGroup No Yes
payComponent No Yes
accrualMethod No Yes
OData Examples
Example 1 – Retrieve data of the time account type with external code ‚ ANNUALLY‘ in JSON format.
URI http://<hostname>/odata/v2/TimeAccountType?$format=json&$filter=externalCode%20eq
%20'ANNUALLY'
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/TimeAccountType('ANNUALLY')", "type" :
"SFOData.TimeAccountType"
},
"externalCode" : "ANNUALLY",
"pepCalendarAutomationLevel" : "NONE",
"accountBookingOffsetInMonths" : "0",
"mdfSystemObjectType" : "TimeAccountType",
"accrualCreationOffset" : null,
"lastModifiedDateTime" : "\/Date(1449745893000+0000)\/",
"levelOfSimulationPrecision" : "CALCULATION",
"mdfSystemRecordId" : "590C33CA5DD84D66B80AA15EB7D3D7A1",
"accrualWaitingPeriodUnit" : null,
"accrualPeriodStartDay" : null,
"mdfSystemEntityId" : "99964CDDCE36447F93EB4919D845660C",
"mdfSystemStatus" : "A",
"externalName_en_US" : "Annually",
"createdDate" : "\/Date(1420714067000)\/",
"terminationRule" : "Accrual",
"mdfSystemRecordStatus" : "N",
"payComponentGroup" : "AnnualizedSalary",
"accrualFrequencyStartDate" : null,
"payoutEligibility" : "ELIGIBLE",
"accrualCalculationMethod" : "STANDARD",
"accountCreationReferenceDate" : "REFERENCE_DAY_MONTH",
"minimumBalanceAllowed" : null,
"periodEndProcessingRule" : null,
"country" : null,
"accountCreationOffsetInMonths" : null,
"createdBy" : "loa",
"createdDateTime" : "\/Date(1420710467000+0000)\/",
"lastModifiedBy" : "country",
"externalName_en_GB" : "Annually",
"mdfSystemEffectiveStartDate" : "\/Date(-2208988800000)\/",
"simulationRule" : null,
"creation" : "RECURRING",
"terminationRuleDataEffectiveDate" : null,
A time type is created for each type of leave. You can use this entity to read the time types created.
Operations Allowed
Table 340:
Operation Description
Major Navigations
Properties
Table 341:
Code Examples
Example 1 – Retrieve data of the time type with external code ‚Maternity‘ in JSON format.
URI http://<hostname>/odata/v2/TimeType?$format=json&$filter=externalCode%20eq%20'Maternity'
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')", "type" :
"SFOData.TimeType"
}, "externalCode" : "Maternity", "mdfSystemObjectType" : "TimeType",
"externalName_ru_RU" : null, "lastModifiedDateTime" : "\/
Date(1421684680000+0000)\/", "mdfSystemRecordId" :
"0B7C1D17963047C0941D4EC2E0E71051", "mdfSystemEntityId" :
"3DFAEAA4A0264BF5B5FD73C53FAED651", "activateCancellationWorkflow" : false,
"mdfSystemStatus" : "A", "externalName_en_US" : "Maternity", "createdDate" : "\/
Date(1420713779000)\/", "mdfSystemRecordStatus" : "N", "country" : null,
"absenceClass" : "UNSPECIFIED", "category" : "ABSENCE", "createdBy" : "daily",
"createdDateTime" : "\/Date(1420710179000+0000)\/", "lastModifiedBy" : "jdepp",
"externalName_en_GB" : null, "mdfSystemEffectiveStartDate" : "\/
Date(-2208988800000)\/", "externalName_en_DEBUG" : null,
"flexibleRequestingAllowed" : false, "workflowConfiguration" : "TimeOffRequest",
"mdfSystemEffectiveEndDate" : "\/Date(253402214400000)\/", "mdfSystemVersionId" :
null, "externalName_defaultValue" : "Maternity", "loaStartEventReason" : "LOA",
"mdfSystemTransactionSequence" : "1", "allowedRequestingIncrement" : null,
"adminWorkflow" : null, "loaEndEventReason" : "LOA_RETURN", "allocationStrategy" :
null, "lastModifiedDateWithTZ" : "\/Date(1421684680000+0000)\/", "countingMethod" :
null, "undeterminedEndDateAllowed" : null, "unit" : "DAYS",
"allowedFractionsUnitDay" : "FULL_DAY", "allowedFractionsUnitHour" : null,
"calculationMethod" : "CALENDARDAYS", "mdfSystemExternalUserVisibility" : null,
"cust_comment" : null, "lastModifiedDate" : "\/Date(1421688280000)\/",
"allocationStrategyNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')/allocationStrategyNav"
}
}, "allowedFractionsUnitDayNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')/
allowedFractionsUnitDayNav"
}
}, "unitNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')/unitNav"
}
}, "countryNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')/countryNav"
}
}, "loaStartEventReasonNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')/
loaStartEventReasonNav"
}
}, "categoryNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')/categoryNav"
}
}, "calculationMethodNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')/calculationMethodNav"
}
}, "mdfSystemExternalUserVisibilityNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')/
mdfSystemExternalUserVisibilityNav"
}
}, "adminWorkflowNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeType('Maternity')/adminWorkflowNav"
2. Example 2 – Navigate to the time account posting rules of the time type with external code ‘VACATION CLT’
URI; http://<hostname>/odata/v2/TimeType('VACATION%20CLT')/timeAccountPostingRules?$format=json
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/
TimeAccountPostingRule(TimeType_externalCode='VACATION CLT',externalCode='1')",
"type" : "SFOData.TimeAccountPostingRule"
}, "TimeType_externalCode" : "VACATION CLT", "externalCode" : "1",
"mdfSystemObjectType" : "TimeAccountPostingRule", "mdfSystemEffectiveEndDate" : "\/
Date(253402214400000)\/", "mdfSystemVersionId" : null, "lastModifiedDateTime" : "\/
Date(1450180676000+0000)\/", "timeAccountType" : "VACATION CLT",
"mdfSystemTransactionSequence" : "1", "mdfSystemRecordId" :
"62E51F9FD82A46B5AAAC01F3E9BD5B21", "createdBy" : "daily",
"mdfSystemExternalUserVisibility" : "n", "mdfSystemEntityId" :
"F3C58E633DBF47D5AAB167179132575C", "createdDateTime" : "\/
Date(1440400672000+0000)\/", "lastModifiedBy" : "country", "mdfSystemStatus" : "A",
"lastModifiedDate" : "\/Date(1450184276000)\/", "mdfSystemEffectiveStartDate" : "\/
Date(-2208988800000)\/", "lastModifiedDateWithTZ" : "\/Date(1450180676000+0000)\/",
"createdDate" : "\/Date(1440407872000)\/", "mdfSystemRecordStatus" : "N",
"mdfSystemExternalUserVisibilityNav" : {
"__deferred" : {
12.1.13 TimeProfile
In a time profile, you specify which time types the employee is allowed to take. The time profile is part of an
employee's job information.
Operations Allowed
Table 342:
Operation Description
Major Navigations
Properties
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations.
Table 343:
Code Example
Example – Retrieve data of the time type profile with time recording variant clock times.
URI
http://<hostname>/odata/v2/TimeTypeProfile?$format=json&$filter=timeRecordingVariant%20eq
%20'CLOCK_TIME' Headers: Authorization: Basic <Base 64 encoded (“user@company:password”)>
{
"d" : {
"results" : [
{
"__metadata" : {
"uri" : "https://localhost:443/odata/v2/TimeTypeProfile('Vacation CLT')", "type" :
"SFOData.TimeTypeProfile"
},
"externalCode" : "Vacation CLT",
"mdfSystemObjectType" : "TimeTypeProfile",
"mdfSystemEffectiveEndDate" : "\/Date(253402214400000)\/", "mdfSystemVersionId" :
null,
"mainBreakTimeType" : "BREAK CLT",
"externalName_ru_RU" : null,
"externalName_defaultValue" : "Vacation CLT",
"lastModifiedDateTime" : "\/Date(1440400906000+0000)\/", "timeRecordingVariant" :
"CLOCK_TIME",
"mdfSystemTransactionSequence" : "1",
"mdfSystemRecordId" : "97613000C22F405FA9B3FB681ABACDD6", "mdfSystemEntityId" :
"EB2F5C3870EB43D0A455DF60B09665FF", "mainAttendanceTimeType" : null,
"mdfSystemStatus" : "A",
"externalName_en_US" : null,
"lastModifiedDateWithTZ" : "\/Date(1440400906000+0000)\/",
"createdDate" : "\/Date(1440408106000)\/",
"mdfSystemRecordStatus" : "N",
"mainESSTimeType" : "VACATION CLT",
"country" : null,
"createdBy" : "daily",
"lastModifiedBy" : "daily",
"createdDateTime" : "\/Date(1440400906000+0000)\/",
"externalName_en_GB" : "Vacation CLT",
"lastModifiedDate" : "\/Date(1440408106000)\/", "mdfSystemEffectiveStartDate" : "\/
Date(-2208988800000)\/", "externalName_en_DEBUG" : null,
"countryNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeTypeProfile('Vacation CLT')/countryNav"
}
},
"mainBreakTimeTypeNav" : {
"__deferred" : {
"uri" : "https://localhost:443/odata/v2/TimeTypeProfile('Vacation CLT')/
mainBreakTimeTypeNav"
}
},
12.1.14 WorkScheduleDayModel
With a work schedule day model, you can define how the number of hours worked on a particular day should look.
You can then use the day models in your work schedule if you choose the Period or Schedule models in your work
schedule.
Operations Allowed
Table 344:
Operation Description
Here you can see the required fields and business keys for this entity. Check the OData API dictionary in your
instance to see the complete list of properties, and check your metadata for navigations, and associations.
Table 345:
Description No No Description
Navigation Properties
Table 346:
Navigation Property Related Entity Description
Code Examples
URI: http://<hostname>/odata/v2/WorkScheduleDayModel('08:00-16:00_15MB_60LB')?$format=JSON
{
"d": {
"__metadata": {
"uri": "https://<hostname>/odata/v2/
WorkScheduleDayModel('08:00-16:00_15MB_60LB')",
12.1.15 DataReplicationProxy
This entity stores references to Employee Central Time data that is relevant for the replication to Employee
Central Payroll and it is used to identify delta changes of time data that should be replicated to Employee Central
Payroll. It only contains a limited number of references to available Employee Centeral Time objects.
Permissions
Table 347:
Permission System Required Setting
Table 348:
Operation Supported Yes/No
Query Yes
Properties
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json. Here are some sample properties.
Table 349:
Property Description
● OUT_OF_SYNC
● IN_SYNC
● DELETED
replicationContentType Type of the object for replication. The object type Employee
Time Valuation Result is supported only.
allowReplicationCorrectionPhase Flag to enable the replication of the proxy during the correc
tion phase
You can get detailed information about the navigation properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following query https://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json. Here are some sample navigations.
Table 350:
employeeTimeValuationResultNav Employee Time Valuation Result Navigation to time sheet data of the em
ployee time valuation result entity
Use Cases
Table 351:
Operation Query
URI http://<Hostname>/odata/v2/DataReplicationProxy?$fil
ter=(earliestReplicationDateTime le datetimeoff
set'2016-09-01T00:00:00Z' and (dataReplicationProxyStatus
eq 'OUT_OF_SYNC' or dataReplicationProxyStatus eq 'DE
LETED') and replicationContentType eq 'EM
PLOYEE_TIME_DATA' and replicationTargetSystem eq
'XXXCLNT100')&$format=json
Response
Sample Code
{
"d": {
"results": {
"__metadata": {
"uri": "https://<hostname>/odata/v2/
DataReplicationProxy('75846be1b99b413f8d0f8872e89d3acf')",
"type": "SFOData.DataReplicationProxy"
},
In this section, you'll find the APIs available for Payroll Time Sheet. Employees are able to record their
attendances, overtime, on-call times, and allowances using the Payroll Time Sheet.
12.2.1 ExternalTimeRecord
The entity represents a time record created outside of the Employee Central system.
The ExternalTimeRecord OData API is used to import employee time records recorded in an external system into
the Employee Central system. After import, the employee time records are converted into time sheet entries.
These time records are later valuated within the Payroll Time Sheet and transferred to Employee Central Payroll.
This OData API performs mass replication of time records from an external time recording system into Employee
Central. It is possible to use the $BATCH directive, which we assume is the standard method to use this API.
Property Yes No
Effective-Dated X
MDF Object X
Child Entity X
Country-Specific Entity X
Full Purge X
Incremental Purge X
Business fields
● <userId>
● <date>
The unique Business Key for the ExternalTimeRecord OData API is a combination of the userId and date.
Required fields
● <userId>
● <date>
Note
You can get detailed information about the entity properties from the OData API dictionary or by exposing the
entity metadata. To do this, use the following queryhttps://<hostname>/odata/v2/Entity('<Your
Entity')?$format=json
Operation Description
POST Updates an object. For an upsert this will be with a full or incre
mental purge.
This is a sample use case for the ExternalTimeRecord OData API - the creation of an external time record with
external time segments. This involves uploading an external time record containing time segments into the time
sheet database in the SAP SuccessFactors system.
● Sending a POST request containing a JSON representation of both External Time Record and External Time
Segment MDF entities
● The response to the POST request
Use Case: Creation of an external time record with external time segments
OData API ExternalTimeRecord - creation of an external time record with external time segments.
1. Request
Operation POST
URI http://<Hostname>/odata/v2/upsert
{
"__metadata":{
"uri":"
ExternalTimeRecord('test1')"
},
"externalCode":"test1",
"date":"\/Date(1453104229000)\/",
"userId":"cgrant1",
"externalTimeSegments":[
{
"externalCode":"",
"hours":4.0
},
{
"externalCode":"",
"hours":4.0
},
{
"externalCode":"",
"hours":1.0
}
]
}
2. Response
Sample Code
1. Request
2. Response
In this example, you can see an imported external time record in the Employee Central System. The record
contains three external time segments, each identified by an individual External Code.
Related Information
13.1 WfRequest
This entity stores basic data of a workflow such as the overall status and the current step number. This is the EC
Workflow used by Employee Central as well as MDF objects.
You can use the following function imports to modify your WfRequest entity: approveWfRequest [page 559],
commentWfRequest [page 561], trejectWfRequest [page 562], sendbackWfRequest [page 564], and
withdrawWfRequest [page 565].
Operations Allowed
Table 355:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 356:
Property Description
Note
In the WorkflowAllowedActionList the filter wfRequestId only supports integers
and strings with the value 'L'. This means, for example, that the integer 224 is
not supported whereas the integer 224L is supported.
module
status
createdOn The date that the workflow request information was added.
lastModifiedBy The ID of the person who made the lastest updated to the entry
Navigation Properties
Table 357:
Navigation Property Related Entity Description
parentWfRequestNav WfRequest_parent
empWfRequestNav EmpWfRequest
wfRequestStepNav WfRequestStep
wfRequestCommentsNav WfRequestComments
wfRequestParticipatorNav WfRequestParticipator
Use Cases
Table 358:
API Call Description
https://<hostname>.com/odata/v2/WfRequest? Get all requests which have the status rejected or cancelled
$filter=status eq 'REJECTED' or status eq
'CANCELLED'&
$select=status,createdBy,totalSteps&
$format=JSON
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/WfRequest(1L)",
"type": "SFOData.WfRequest"
Related Information
Use the Todo entity to retrieve your assigned workflow requests. The Todo entity contains the list of tasks
assigned to a user. You will find a workflow item in the following Todo task categories 14 ( HRIS Employee Change
Requests Category26), 17 (Generic Object Category), 18 (Absence Management Category), 24 (IT Category), and
25 ( Deductions Category) .
Tell me more
1.Run a Todo query for the relevant task category (14, 17, 18, 24, or 25)
Run a Todo query for the relevant task category (14, 17, 18, 24, or 25)
For this example, we'll use the task category 14 ( HRIS Employee Change Requests Category26):
Sample Response
Sample Code
<m:properties>
<d:categoryId>14</d:categoryId>
<d:todos m:type="Bag(SFOData.ToDoBean)">
<d:element>
<d:categoryId>14</d:categoryId>
<d:completedDate m:null="true" />
<d:dueDate m:null="true" />
<d:dueDateOffSet m:type="Edm.Int32">0</d:dueDateOffSet>
<d:entries m:type="Bag(SFOData.ToDoEntry)">
Here you can see that in there is one workflow item, subjectId 462 in the task category 14 (HRIS Employee Change
Requests Category26). Let's now look at our wfRequest query.
Sample Response
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>/odata/v2/WfRequest(462L)",
"type": "SFOData.WfRequest"
},
"wfRequestId": "462",
"module": "HRIS",
"status": "PENDING",
"currentStepNum": 1,
"lastModifiedDateTime": "/Date(1391090611000+0000)/",
"lastModifiedOn": "/Date(1391072611000)/",
"totalSteps": 1,
"url": "https://<hostname>/sf/hrisworkflowapprovelink?
workflowRequestId=V2-ypU9jRAxxzV2pyMHsQn1BQ%3D
%3D&prevPage=HOME&company=ACE1321&username=admin",
"reminderSentDate": null,
"createdOn": "/Date(1330523150000)/",
"createdBy": "admin",
"createdDateTime": "/Date(1330541150000+0000)/",
"lastModifiedBy": "admin",
"parentWfRequestId": null,
"workflowAllowedActionListNav": {
"__deferred": {
"uri": "https://<hostname>/odata/v2/WfRequest(462L)/
workflowAllowedActionListNav"
}
You can use the URL in the response to access your workflow item on the UI.
Note
The Todo entity is user-centric and will only return the ToDos for the API login user.
You can read up on the Todo entitity, and what task categories are supported here.
13.2 WfRequestComments
Table 359:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 360:
Property Description
Note
createdOn The date that the workflow request information was added.
lastModifiedBy The ID of the person who made the lastest updated to the en
try
Navigation Properties
Table 361:
Navigation Property Related Entity Description
Table 362:
API Call Description
https://<hostname>.com/odata/v2/ Get all comments created by admin which have the action
WfRequestComments?$filter=(actionType eq type initiate or decline
'INITIATE' or actionType eq 'DECLINE') and
createdBy eq 'admin'&
$select=createdBy,actionType&$format=JSON
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/
WfRequestComments(46L)",
"type": "SFOData.WfRequestComments"
},
"createdBy": "admin",
"actionType": "INITIATE"
}
]
}
}
Related Information
13.3 WfRequestParticipator
Table 363:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 364:
Property Description
Note
In the WorkflowAllowedActionList the filter wfRequestId
only supports integers and strings with the value 'L'. This
means, for example, that the integer 224 is not supported
whereas the integer 224L is supported.
roleId
relatedTo
processingOrder
participatorType
lastModifiedBy The ID of the person who made the lastest updated to the en
try
actorType
Table 365:
Navigation Property Related Entity Description
Related Information
13.4 WfRequestStep
Operations Allowed
Table 366:
Operation Description
UPSERT/POST Update (upsert, full or incremental purge) an object, such as employee, person or foundation.
Properties
Table 367:
Property Description
Note
In the WorkflowAllowedActionList the filter wfRequestId
only supports integers and strings with the value 'L'. This
means, for example, that the integer 224 is not supported
whereas the integer 224L is supported.
stepNum
actionType
approverType
ownerId
processedBy
relatedTo
role
status
createdOn The date that the workflow request step information was
added.
lastModifiedBy The ID of the person who made the lastest updated to the en
try
Navigation Properties
Table 368:
Navigation Property Related Entity Description
wfRequestNav WfRequest
dynamicRoleNav FODynamicRole
positionNav Position
processedByNav User
ownerNav User
Table 369:
API Call Description
https://<hostname>.com/odata/v2/
WfRequestStep?$filter=createdBy eq
'cgrant1' and ownerId eq 'cgrant1' and
status eq 'COMPLETED'&
$select=wfRequestStepId,stepNum,ownerId,ap
proverType&$format=JSON
Code Examples
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com:443/odata/v2/WfRequestStep(1L)",
"type": "SFOData.WfRequestStep"
},
"wfRequestStepId": "1",
"stepNum": "1",
"approverType": "ROLE",
"ownerId": "cgrant1"
}
]
}
}
Related Information
13.5 WorkflowAllowedActionList
Lets you see what actions a consumer can take on a the WfRequest entity. Using Boolean values TRUE/FALSE,
you can see what a consumer can or cannot do for a given workflow step. The workflow steps include returning,
withdrawing, commenting, declining, updating, resubmitting, or allowing a delegate to decline, revoke, or grant a
WfRequest.
Table 370:
Operation Description
Properties
Table 371:
Property Description
Note
Navigation Properties
Table 372:
Navigation Property Related Entity Description
Use Cases
Table 373:
API Call Description
Code Examples
Sample Code
Here is a code extract from such a query focussing on one particular workflow request ID:
workflowAllowedActionListNav: {
results: [1]
0: {
__metadata: {
uri: "https:/<hostname.com>/odata/v2/WorkflowAllowedActionList(1563L)"
type: "SFOData.WorkflowAllowedActionList"
}-
wfRequestId: "1563"
allowResubmit: false
allowReject: false
allowDelegateGrant: false
allowDelegateDecline: false
allowApprove: false
allowWithdraw: true
allowSendback: false
allowPostComment: true
allowUpdateRequest: false
allowDelegateRevoke: false
}-
-
}
Related Information
Function imports modify an entity. You use them as you would any OData API.
Example
The function import rejectWfRequest can be used in the following POST Operation:
https://<hostname>/odata/v2/withdrawWfRequest?wfRequestId=1234L
When you post this request, and it is successful, you'll change the status of the request to Rejected and the code
looks like this:
<d:WfRequestActionResponse>
<d:element m:type="SFOData.WfRequestActionResponse">
<d:status>success</d:status>
<d:wfRequestId m:type="Edm.Int64">1234L</d:wfRequestId>
</d:element>
</d:WfRequestActionResponse>
13.6.1 approveWfRequest
Lets you appove a workflow request assuming that you have authorization to approve the next step in the
workflow as described in the topic WorkflowAllowedActionList.
Operations Allowed
Table 374:
Operation Description
Table 375:
Parameter Description Type
Use Case
Table 376:
API Call Description
Code Examples
<d:WfRequestActionResponse>
<d:element m:type="SFOData.WfRequestActionResponse">
<d:status>success</d:status>
<d:wfRequestId m:type="Edm.Int64">1234L</d:wfRequestId>
</d:element>
</d:WfRequestActionResponse>
Error Codes
Table 377:
Error Code Description
COE_GENERAL_BAD_REQUEST Message will tell you if the error is due to lack of user authori
zation or if there is an issue with the workflow itself.
Related Information
Lets you comment a workflow request assuming that you have authorization in the WorkflowAllowedActionList.
Operations Allowed
Table 378:
Operation Description
Parameters
Table 379:
Parameter Description Type
Use Case
Table 380:
API Call Description
Code Examples
Sample Code
<d:WfRequestActionResponse>
<d:element m:type="SFOData.WfRequestActionResponse">
<d:status>success</d:status>
<d:wfRequestId m:type="Edm.Int64">1563</d:wfRequestId>
</d:element>
</d:WfRequestActionResponse>
Table 381:
Error Code Description
COE_GENERAL_BAD_REQUEST Message will tell you if the error is due to lack of user authori
zation or if there is an issue with the workflow itself.
Related Information
13.6.3 rejectWfRequest
Lets you reject a workflow request assuming that you have authorization in the WorkflowAllowedActionList.
Operations Allowed
Table 382:
Operation Description
Parameters
Table 383:
Parameter Description Type
Table 384:
API Call Description
Code Examples
Sample Code
<d:WfRequestActionResponse>
<d:element m:type="SFOData.WfRequestActionResponse">
<d:status>success</d:status>
<d:wfRequestId m:type="Edm.Int64">1234L</d:wfRequestId>
</d:element>
</d:WfRequestActionResponse>
Error Codes
Table 385:
Error Code Description
COE_GENERAL_BAD_REQUEST Message will tell you if the error is due to lack of user authori
zation or if there is an issue with the workflow itself.
Related Information
Lets you send back a workflow request assuming that you have authorization in the WorkflowAllowedActionList.
Operations Allowed
Table 386:
Operation Description
Parameters
Table 387:
Parameter Description Type
Use Case
Table 388:
API Call Description
Code Examples
Sample Code
<d:WfRequestActionResponse>
<d:element m:type="SFOData.WfRequestActionResponse">
<d:status>success</d:status>
<d:wfRequestId m:type="Edm.Int64">1234L</d:wfRequestId>
</d:element>
</d:WfRequestActionResponse>
Table 389:
Error Code Description
COE_GENERAL_BAD_REQUEST Message will tell you if the error is due to lack of user authori
zation or if there is an issue with the workflow itself.
Related Information
13.6.5 withdrawWfRequest
Lets you withdraw a workflow request assuming that you have authorization in the WorkflowAllowedActionList.
Operations Allowed
Table 390:
Operation Description
Parameters
Table 391:
Parameter Description Type
Table 392:
API Call Description
Code Examples
Sample Code
<d:WfRequestActionResponse>
<d:element m:type="SFOData.WfRequestActionResponse">
<d:status>success</d:status>
<d:wfRequestId m:type="Edm.Int64">1234L</d:wfRequestId>
</d:element>
</d:WfRequestActionResponse>
Error Codes
Table 393:
Error Code Description
COE_GENERAL_BAD_REQUEST Message will tell you if the error is due to lack of user authori
zation or if there is an issue with the workflow itself.
Related Information
If you want to save time when adding new employees to your organization, you can use an Upsert operation. This
will prove less time-consuming that adding the employees one-by-one in the Employee Central UI.
At a minimum you can insert the User, PerPerson, EmpEmployment, EmpJob, and PerPersonal entity to add an
employee.
Note
The order which you perform the Upsert operations is critical. Be sure to follow it.
1. User entity
2. PerPerson
3. EmpEmployment
4. EmpJob
5. PerPersonal
Related Information
When you add a new employee, you need to upsert the User entity. The order in which you upsert your entities for
adding a new employee is crucial and the user entity is the first one. The other ones are PerPerson (2nd upsert),
EmpEmployment (3rd upsert), EmpJob (4th upsert) and PerPersonal (5th upsert).
Good to know
When you upsert the user entity, this also creates the PerPerson and EmpEmployment entity. However, both these
entities remain hidden until you explicitly upsert them.
URI: http://<Hostname>.com/odata/v2/upsert
Payload
Source Code
{
"__metadata": {
"uri": "User('cgrant')"
},
"username": "carlagrant",
"status": "Active",
"userId": "cgrant"
}}
Tip
To see the required fields for this entity for your instance, check your OData dictionary. There you'll see any other
insertable fields available and you can add them to your payload, if required.
Response
When the insert is successful, you'll have the following response. Please note that the operation always returns
status 200 (OK) with a response body indicating all Upsert results. Individual Upsert failures are not reported
as errors.
Source Code
<feed>
<entry>
<content type="application/xml">
<m:properties>
<d:key>cgrant</d:key>
<d:status>OK</d:status>
<d:editStatus>INSERTED</d:editStatus>
<d:message m:null="true" />
<d:index m:type="Edm.Int32">0</d:index>
<d:httpCode m:type="Edm.Int32">201</d:httpCode>
<d:inlineResults m:type="Bag(SFOData.UpsertResult)" />
</m:properties>
</content>
</entry>
</feed>
When you add a new employee, you need to upsert the PerPerson entity. The order in which you upsert your
entities for adding a new employee is crucial and the PerPerson entity is the second one when you use the
minimum number of entities to add a new employee. The other ones are User (first upsert), this one PerPerson
(2nd upsert), EmpEmployment (3rd upsert), EmpJob (4th upsert) and PerPersonal (5th upsert).
Good to know
Although the PerPerson entity is created when the user entity is upserted, it remains hidden. It will only become
visible when:
URI: http://<Hostname>.com/odata/v2/upsert
Payload
Source Code
{
"__metadata": {
"uri": "PerPerson('cgrant')"
},
"personIdExternal": "grantcarla",
"userId": "cgrant"
}}
Tip
To see the required fields for this entity for your instance, check your OData dictionary. There you'll see any other
insertable fields available and you can add them to your payload, if required.
Response
Source Code
<feed>
<entry>
<content type="application/xml">
<m:properties>
<d:key m:null="true" />
<d:status>OK</d:status>
<d:editStatus>UPSERTED</d:editStatus>
<d:message m:null="true" />
<d:index m:type="Edm.Int32">0</d:index>
<d:httpCode m:type="Edm.Int32">200</d:httpCode>
<d:inlineResults m:type="Bag(SFOData.UpsertResult)" />
</m:properties>
</content>
</entry>
</feed>
Related Information
When you add a new employee, you need to upsert the EmpEmployment entity. The order in which you upsert
your entities for adding a new employee is crucial and the EmpEmployment entity is the third one when you use
the minimum number of entities to add a new employee. The other ones are User (1st upsert), PerPerson (2nd
upsert),this one EmpEmployment (3rd upsert), EmpJob (4th upsert), and PerPersonal (5th upsert).
Good to know
When you upsert EmpEmployment, the PerPerson entity will also become visible assuming that it has been
explicitly upserted (and not just created as a hidden entity during the User upsert).
URI: http://<Hostname>.com/odata/v2/upsert
Sample Code
Source Code
{"__metadata": {
"uri": "EmpEmployment(personIdExternal='grantcarla',userId='cgrant')"
},
"startDate":"/Date(1388534400000)/",
"personIdExternal":"grantcarla",
"userId":"cgrant"
}}
Tip
To see the required fields for this entity, check the OData dictionary in your company instance. You can also see
the other insertable fields and can add them to your payload, if required.
Response
When the insert is successful, you'll have the following response. Please note that the operation always returns
status 200 (OK) with a response body indicating all Upsert results. Individual Upsert failures are not reported
as errors.
Source Code
<feed>
<entry>
<content type="application/xml">
<m:properties>
<d:key m:null="true" />
<d:status>OK</d:status>
<d:editStatus>UPSERTED</d:editStatus>
<d:message m:null="true" />
<d:index m:type="Edm.Int32">0</d:index>
<d:httpCode m:type="Edm.Int32">200</d:httpCode>
<d:inlineResults m:type="Bag(SFOData.UpsertResult)" />
</m:properties>
</content>
</entry>
</feed>
Related Information
When you add a new employee, you need to upsert the EmpJob entity. The order in which you upsert your entities
for adding a new employee is crucial and the EmpJob entity is the fourth one when you use the minimum number
of entities to add a new employee. The other ones are User (1st upsert), PerPerson (2nd upsert), EmpEmployment
(3rd upsert), this one, EmpJob (4th upsert), and PerPersonal (5th upsert).
URI: http://<Hostname>.com/odata/v2/upsert
Payload
Source Code
{"__metadata": {
"uri": "EmpJob"
},
"jobCode":"ADMIN-1",
"userId":"cgrant",
"startDate":"/Date(1388534400000)/",
"eventReason":"HIRNEW",
"company":"ACE_USA",
"businessUnit":"ACE_CORP",
"managerId":"NO_MANAGER"
}
}
}
Tip
To see the required fields for this entity for your instance, check your OData dictionary. There you'll see any other
insertable fields available and you can add them to your payload, if required.
Response
When the insert is successful, you'll have the following response. Please note that the operation always returns
status 200 (OK) with a response body indicating all Upsert results. Individual Upsert failures are not reported
as errors.
Source Code
<feed>
<entry>
<content type="application/xml">
<m:properties>
<d:key m:null="true" />
<d:status>OK</d:status>
<d:editStatus>UPSERTED</d:editStatus>
Related Information
When you add a new employee, you need to upsert the PerPersonal entity. The order in which you upsert your
entities for adding a new employee is crucial and the PerPersonal entity is the last one when you use the minimum
number of entities to add a new employee. The other ones are User (first upsert), PerPerson (2nd upsert),
EmpEmployment (3rd upsert), EmpJob (4th upsert) and this one PerPersonal (5th upsert).
URI: http://<Hostname>.com/odata/v2/upsert
Payload
Source Code
{ "__metadata":{
"uri":"PerPersonal(personIdExternal='grantcarla',startDate=datetime'2014-01-01T00:
00:00')"},
"personIdExternal":"grantcarla",
"namePrefix": "Ms",
"gender":"F",
"initials": "cg",
"firstName":"Carla",
"lastName":"Grant"
}
To see the required fields for this entity for your instance, check your OData dictionary. There you'll see any other
insertable fields available and you can add them to your payload, if required.
Response
When the insert is successful, you'll have the following response. Please note that the operation always returns
status 200 (OK) with a response body indicating all Upsert results. Individual Upsert failures are not reported
as errors.
Source Code
<feed>
<entry>
<content type="application/xml">
<m:properties>
<d:key m:null="true" />
<d:status>OK</d:status>
<d:editStatus>UPSERTED</d:editStatus>
<d:message m:null="true" />
<d:index m:type="Edm.Int32">0</d:index>
<d:httpCode m:type="Edm.Int32">200</d:httpCode>
<d:inlineResults m:type="Bag(SFOData.UpsertResult)" />
</m:properties>
</content>
</entry>
</feed>
Related Information
Background
In this topic, we’re talking about external and internal user data.
Internal user data refers to EC users, that is employees, as well as any users that have a dependent relationship
with an EC user (for example, a spouse, a child, or, an emergency contact).
The EC entitities, EmpEmployment, PerAddressDEFLT, PerEmail, PerPhone, PerPerson, and PerPersonal are
often reused by other non-EC modules to store user data. This data is external user data. Up to now, you haven't
been able to filter out this external user data for PerAddressDEFLT, PerEmail, PerPhone, or for PerPersonal . So, if,
for example you’re using EC OData APIs for a scenario such as payroll replication, your response could include
applicants from Recruiting. And, conversely, you have not been able to include external user data for
EmpEmployment or PerPerson. Now, however, we're offering filterable and selectable fields to model queries to
meet your requirements.
We're offering you the following Boolean fields to use with $filter:
For EmpEmployment, you can use this combination to return external user data:
Table 394:
Field Type Nullable Required Creatable Updatable Upserta Visible Sortable Filterable
ble
includeAll Edm.Boo True False False False False False True True
Records lean
isECRe Edm.Boo True False False False False True False True
cord lean
includeAllRecords works on the root entity only. If you specify it on the navigation entity, it won't work.
Works:
Query: https://<hostname>.com/odata/v2/PerPerson?$expand=personalInfoNav&
$filter=includeAllRecords eq true
Query: https://<hostname>.com/odata/v2/PerPerson?$expand=personalInfoNav&
$filter=personalInfoNav/includeAllRecords eq true
Your want your query to return You'll need to Use the following filter
Internal user data Filter out external user data Option 1: isECRecord=true
Option 3: includeAllRecords=false
Option 5: no filter
External user data Filter out internal user data isECRecord=false, includeAllRecords=
true
Note
Only available for EmpEmployment
External and internal user data Include external and internal user data includeAllRecords= true
Query: https://<hostname>.com/odata/v2/PerPhone
Response
Sample Code
Extract from response
<m:properties>
<d:personIdExternal>llll</d:personIdExternal>
<d:phoneType>5845</d:phoneType>
<d:extension m:null="true"></d:extension>
<d:createdOn m:type="Edm.DateTime">2011-03-17T21:39:02</
d:createdOn>
<d:isPrimary m:type="Edm.Boolean">true</d:isPrimary>
<d:phoneNumber>707 2000</d:phoneNumber>
<d:createdBy>admin</d:createdBy>
<d:lastModifiedBy>admin</d:lastModifiedBy>
<d:createdDateTime
m:type="Edm.DateTimeOffset">2011-03-17T21:39:02Z</d:createdDateTime>
<d:lastModifiedOn m:type="Edm.DateTime">2011-03-17T21:39:02</
d:lastModifiedOn>
<d:lastModifiedDateTime
m:type="Edm.DateTimeOffset">2011-03-17T21:39:02Z</d:lastModifiedDateTime>
</m:properties>
Sample Code
Extract from response
<m:properties>
<d:personIdExternal>GAdams</d:personIdExternal>
<d:userId>GAdams</d:userId>
<d:startDate m:type="Edm.DateTime">1900-01-01T00:00:00</
d:startDate>
<d:eligibleForStock m:null="true"></d:eligibleForStock>
<d:initialOptionGrant m:null="true"></d:initialOptionGrant>
<d:payrollEndDate m:null="true"></d:payrollEndDate>
<d:serviceDate m:null="true"></d:serviceDate>
<d:professionalServiceDate m:null="true"></
d:professionalServiceDate>
<d:okToRehire m:null="true"></d:okToRehire>
<d:regretTermination m:null="true"></d:regretTermination>
<d:customString23 m:null="true"></d:customString23>
<d:endDate m:null="true"></d:endDate>
<d:lastModifiedDateTime
m:type="Edm.DateTimeOffset">2016-06-21T08:54:09Z</d:lastModifiedDateTime>
<d:eligibleForSalContinuation m:null="true"></
d:eligibleForSalContinuation>
Response
Sample Code
Extract from response
<m:properties>
<d:personIdExternal>121</d:personIdExternal>
<d:userId>121</d:userId>
<d:startDate m:type="Edm.DateTime">2011-12-05T00:00:00</
d:startDate>
<d:eligibleForStock m:type="Edm.Boolean">false</
d:eligibleForStock>
<d:initialOptionGrant m:null="true"></d:initialOptionGrant>
<d:payrollEndDate m:type="Edm.DateTime">2011-11-28T00:00:00</
d:payrollEndDate>
<d:serviceDate m:null="true"></d:serviceDate>
<d:professionalServiceDate m:null="true"></
d:professionalServiceDate>
<d:okToRehire m:null="true"></d:okToRehire>
<d:regretTermination m:type="Edm.Boolean">false</
d:regretTermination>
<d:customString23 m:null="true"></d:customString23>
<d:endDate m:null="true"></d:endDate>
<d:lastModifiedDateTime
m:type="Edm.DateTimeOffset">2011-12-06T00:00:42Z</d:lastModifiedDateTime>
<d:eligibleForSalContinuation m:type="Edm.Boolean">false</
d:eligibleForSalContinuation>
<d:StockEndDate m:type="Edm.DateTime">2011-11-28T00:00:00</
d:StockEndDate>
<d:assignmentClass>ST</d:assignmentClass>
<d:lastDateWorked m:type="Edm.DateTime">2011-11-28T00:00:00</
d:lastDateWorked>
<d:salaryEndDate m:type="Edm.DateTime">2011-11-28T00:00:00</
d:salaryEndDate>
<d:isECRecord m:type="Edm.Boolean">true</d:isECRecord>
A person UUID (unique universal identifier) is now available for integration and import scenarios.
Background
We’ve introduced the concept of a person UUID for the entire SAP SuccessFactors HCM Suite. When a new hire or
user is created, the system generates this identifier – called “perPersonUuid”. This field is immutable meaning that
once the field is populated with a value, it cannot be changed.
In the SAP SF HCM Suite, you can now expose perPersonUuid for integration and import scenarios for all
employees. So even if the employment field IS_EC_SYSTEM_OF_RECORD=F and the record is for a non-EC user,
the perPersonUuid can be exposed.
perPersonUuid cannot be queried directly, but is available from the User entity with the new navigation
personKeyNav.
perPersonUuid is exposed regardless of data model configuration, RBP settings, or provisioning settings.
Tell me more
These tables show you the properties for PersonKey, PersonKeyNav and perPersonUuid.
Property Type Nullable Required Creatable Updatable Upserta Visible Sortable Filterable
ble
Name
personI Edm.Strin False True False False False True True True
dExternal g
personId Edm.Int64 True False False False False True True True
perPerso Edm.Strin True False False False False True True True
nUuid g
False False False False True False True SFO User PersonKey
8¸™Þ¢pNÓ–Ù Ù=Si�Çy›
8¸™é¢~Nóô
Key_User
Good to know
Note
Note - to add it to PerPerson, you have to:
○ Add <hris-field id="per-person-uuid" visibility="both"> to personInfo hris-element in your data model
configuration.
○ Enable RBP and EDDP in provisioning
To query it, personKeyNav has now been added to the User entity and you use $expand to expose perPersonUuid.
Request: https://<hostname.com/odata/v2/User('admin')?$format=json&$expand=personKeyNav&
$select=personKeyNav
Response
Sample Code
Extract from response
{
"d": {
"__metadata": {
"uri": "https://<hostname>.com/odata/v2/User('admin')",
"type": "SFOData.User"
},
"personKeyNav": {
"__metadata": {
"uri": "https://<hostname>.com/odata/v2/PersonKey('admin')",
"type": "SFOData.PersonKey"
},
"personIdExternal": "admin",
"personId": "2",
"perPersonUuid": "3A085DB0D9184B49B0E3E70D6F07EB1A"
}
}
},
Request: https://<hostname>.com/odata/v2/User('admin')?$format=json&
$expand=personKeyNav&$filter=personKeyNav/pePersonUuid eq
"3A085DB0D9184B49B0E3E70D6F07EB1A"
Response
Sample Code
Extract from response
Response:
Related Information
Background
FOWfConfig contains workflow information but - as with all entity fields - you can only read the fields that have the
attribute visible=true. In FOWfConfig, this means that you couldn't read the following fields:
However, you can use this nav, wfStepApproverNav to navigate to FOWfConfigStepApprover where these fields
have the attribute visible=true.
Being able to read these fields means that you can get much more detailed workflow information.
You can access these fields for more detailed information as follows:
Tell me more
wfStepApproverNav: Properties
Sample Code
Extract from $metadata
<NavigationProperty Name="wfStepApproverNav"
sap:required="false"
sap:creatable="false"
sap:updatable="false"
sap:upsertable="false"
sap:visible="true"
sap:sortable="true"
sap:filterable="true"
Relationship="SFOData.FOWfConfig_FOWfConfigStepApprover"
FromRole="FOWfConfig" ToRole="FOWfConfigStepApprover_ref"
sap:label="wfStepApproverNav">
</NavigationProperty>
FOWfConfigStepApprover: Properties
Sample Code
Extract from $metadata focussing on the fields that have the attribute visible=true (up to now only availabe in
FOWfConfig with the attribute visible=false)
<EntityType Name="FOWfConfigStepApprover">
<Property Name="actionType" Type="Edm.String" Nullable="true"
sap:required="false" sap:creatable="false" sap:updatable="false"
sap:upsertable="false" sap:visible="true" sap:sortable="false"
sap:filterable="false" sap:label="Edit Transaction"></Property>
<Property Name="approverRole" Type="Edm.String" Nullable="true"
sap:required="false" sap:creatable="false" sap:updatable="false"
sap:upsertable="false" sap:visible="true" sap:sortable="false"
sap:filterable="false" sap:label="Approver Role"></Property>
<Property Name="approverType" Type="Edm.String" Nullable="true"
sap:required="false" sap:creatable="false" sap:updatable="false"
sap:upsertable="false" sap:visible="true" sap:sortable="false"
sap:filterable="false" MaxLength="32" sap:label="Approver Type"></Property>
<Property Name="context" Type="Edm.String" Nullable="true"
sap:required="false" sap:creatable="false" sap:updatable="false"
Response
Sample Code
{
"d": {
"__metadata": {
"uri": "https://<hostname>.com/odata/v2/FOWfConfig('LOA')",
"type": "SFOData.FOWfConfig"
},
"externalCode": "LOA",
"createdOn": "/Date(1300533482000)/",
"futureDatedAlternateWorkflow": null,
"createdBy": "admin",
"description": "HR Business Partner assigned to manager's business unit",
"name": "Leave of Absence",
"lastModifiedBy": "admin",
"createdDateTime": "/Date(1300533482000+0000)/",
"remindIndays": null,
"lastModifiedOn": "/Date(1323196467000)/",
"lastModifiedDateTime": "/Date(1323196467000+0000)/",
"isDelegateSupported": null,
"wfStepApproverNav": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com/odata/v2/
FOWfConfigStepApprover(externalCode='LOA',stepNum=1L)",
"type": "SFOData.FOWfConfigStepApprover"
},
"stepNum": "1",
"externalCode": "LOA",
"approverPositionRelationship": null,
"lastModifiedDateTime": "/Date(1323196467000+0000)/",
Response
Sample Code
Extract from response
....
<entry>
Related Information
What's new?
The mdf entities, SecondaryAssignments and SecondaryAssignmentsItem are now available. This means that it is
now possible to know which employment contract is the primary one for replication scenarios. In a nutshell you
can now build a concurrent employment replication from Employee Central to other 3rd Party systems using
OData APIs. Please note that secondary employment is also known as concurrent employment.
Previously it was not possible to differentiate primary from secondary employments using OData APIs. By offering
SecondaryAssignments and SecondaryAssignmentsItems, important data has been made available in one single
API call and you benefit from:
The PerPerson entity now has a navigation secondaryAssignmentsNav that lets you navigate to the MDF entity
SecondaryAssignments.
Tell me more
SecondaryAssignments has a business key externalCode (Person ID External) meaning that it references a
person. It has a one to multiple association with the MDF entity SecondaryAssignmentsItem.
SecondaryAssignmentsItems contains the userSysId (Employment/User ID) – this is the unique user ID generated
when a secondary employment is created. It is a child entity of SecondaryAssignments. These assignments are
created and maintained automatically based on the creation or editing of Concurrent Employment.
Both entities are effective-dated. If the concept of effective dating is new to you, please take a look at Effective
Dating so that you can make the most out of this new entity.
In the PerPerson entity, you use the secondaryAssignmentsNav, a visible, sortable, and filterable field to build a
query that navigates to the entity SecondaryAssignments.
GET Operation: Retrieves the secondaryAssignmentsNav which in turn will return the
SecondaryAssignmentsItems, that is information about the secondary employment.
Request: https://<hostname>.com/odata/v2/PerPerson?$format=json&$filter=personIdExternal
%20eq%20'jsmith'&$expand=secondaryAssignmentsNav/allSfProcesses
Response
Sample Code
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://<hostname>.com/odata/v2/PerPerson('jsmith')",
"type": "SFOData.PerPerson"
},
"personIdExternal": "jsmith",
"dateOfBirth": null,
"lastModifiedOn": "/Date(1303743709000)/",
"lastModifiedDateTime": "/Date(1303743709000+0000)/",
"dateOfDeath": null,
"createdOn": "/Date(1303743708000)/",
"countryOfBirth": null,
"createdBy": "v4admin",
"regionOfBirth": null,
"createdDateTime": "/Date(1303743708000+0000)/",
"lastModifiedBy": "v4admin",
"personId": "11",
"personRerlationshipNav": {
"__deferred": {
"uri": "https://<hostname>.com/odata/v2/
PerPerson('jsmith')/personRerlationshipNav"
}
},
"emergencyContactNav": {
"__deferred": {
"uri": "https://<hostname>.com/odata/v2/
PerPerson('jsmith')/emergencyContactNav"
}
},
Upsert Operation: Retrieves the secondaryAssignmentsNav which in turn will return the
SecondaryAssignmentsItems, that is information about the secondary employment. There is not often a business
case for this operation but it has been provided to support the cloning or transfer of data between similar
instances in a different environment. In this example here, user system ID (represented by the externalcode) for
the primary employment is PrimaryEmployment and the userSysID for secondary employment is represented by
301 (a number automatically generated when a secondary employment is created).
Request: https://<hostname>.com/odata/v2/upsert
Payload Data
Sample Code
You can take a look at the tips and FAQs here to see if they can answer your questions or help you with your APIs.
In some cases, you'll find a brief explanation, and others will guide you to existing topics for your answer.
The permission setting, Admin access to OData API lets users use Basic Authorization to make API calls. It's
available in Permission Settings under Administrator Settings in Manager Integration Tools.
Two authentication types are available in OData APIs - HTTP Basic Authorization and OAuth 2.0.
HTTP Basic Authorization is less secure but simpler to set up and use - so you might want to use it for testing or in
test clients. OAuth is more complex to set up but more secure.
In EC OData APIs, you use either Basic Authorization or OAuth 2.0 as an authentication type.
The main difference between basic authorization and OAuth 2.0 is the level of security each type offers for making
API calls; basic authorization is less secure but easier to set up and OAuth 2.0 is more secure and more complex to
set up. Basic Authorization might be useful for test clients and OAuth 2.0 for productive environments. Take a look
at these documents for more information:Authentication Types for OData API [page 593]
The OData API provides two types of authentication: HTTP Basic Authentication (Basic Auth) and authentication
using OAth 2.0. Basic Auth requires users to have admin access to the OData API and have valid accounts with
usernames and passwords. OAuth 2.0 lets all users log in regardless of whether they are SSO users, so long as
they have a valid token and the OAuth client is registered.
You must have a admin access to OData API to login using HTTP Basic Authentication (Basic Auth). For Basic
Auth, the authorization header is constructed in the following way:
● Username, Company ID, and password are combined into a string as such: "username@company
ID:password"
● The resulting string literal is then encoded using Base64.
● The authorization method ("Basic") followed by a space is then put before the encoded string. For example,
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Note
When SSO is enabled, users cannot use Basic Auth. A partial workaround is available through a feature called
partial org sso for App login. Users who have been assigned the permission Admin Access to OData API from the
RBP system can log in using a password-based login, even if they are an SSO user. Note that Basic Auth should
be used only by users who need administrative access for system-to-system data integration.
Once OData is enabled, you must authorize access to the API for an Role-Based Performance (RBP) system to
activate Basic Auth for a given user.
After OData is enabled, to activate Basic Auth for a given user you must authorize access to the API for a user-
based system
1. Click Administrative Privileges Integration Tools , and select Admin access to OData API.
2. On the Managing Administrative Privilege page, select the Employee Export and Employee Import checkboxes
to grant those permissions to the given user.
You will not need to re-enter this information for subsequent queries until the browser is closed. If the user name
and password verification fails, you will need to open a new window and try again
Note
When you query in atom format in Firefox, the xml result will not be displayed, because Firefox regards atom
format as RSS content by default. You can check the result in JSON format or view the source code to check the
query result.
Your SuccessFactors HCM Suite administrator sets password policies for all users in the system, including the
timing for password expirations. However, you may want to set different expiration times for passwords for
intergrations that are built against a specially designed API user account. You can set exceptions to the password
policy for your API user, and specify a different password expiration (maximum password age) policy. To maintain
security, users who have password policy exceptions are required to have an IP address restriction to connect to
the API . Password policy exceptions are set in Admin Tools Company Settings Password & Login Policy
Settings . Select the link labeled “Set API login exceptions…” to add a custom password expiration. You must
provide a username, and the desired maximum password age in days (-1 means the password will not expire,
though we do not recommend doing that). You must also provide an IP address restrictions for this user.
OAuth 2.0 lets all users log in regardless of whether they are SSO users . If you are planning to use OAuth 2.0 for
authentication, you will first need to register your OAuth client, and set up the permissions required for. this
registration. Then you can register your OAuth client application.
From the admin menu Manage Permission Roles, select the desired role for which you want to add the permission.
As a best practice, create role named "API Administrator" . Under the Manage Integration Tools link, select the
Manage OAuth2 Client Applications checkbox.
After you have done this, you will see a link, Manage OAuth2 Client Applicationsunder the Company Settings
category in the new admin tools, and under Integration Tools in the older administration tools interface.
From the Admin Menu click Manage Security Administrative Privileges . For the user you are logged in as,
look under Integration Tools and check the box under Access to OAuth 2 Management.
After you have done this, you will see a link under Integration Tools to where you can register your OAuth client.
To register an OAuth client, log into your application instance with an administrator account. From the Admin
menu click Manage OAuth2 Client Applications Register New Client Application . After you register an OAuth
client, any user of the registered client can connect to SuccessFactors HCM Suite using this method.
Enter the following parameters in the form that is displayed, and clickRegister:
Table 399:
VALUE DESCRIPTION
Company The name of your company. This value is pre-filled based on the instance of
the company currently logged in.
Application URL A unique URL of the page that the client wants to display to the end user. The
page might contain more information about the client application. This is
needed for 3-legged OAuth, however it is not currently supported.
X.509 Certificate The certificate corresponding to the private and public key used in the OAuth
2.0 authentication process. In this flow, the SuccessFactors HCM Suite sys
tem will need the public key (the certificate) and the client application will
have the private key. To register a client application, you will need to install
the public key (aka certificate) in SuccessFactors HCM Suite. If you supply
that certificate, you must use the RSA-SHA1 signature type for authenticat
ing. As an optional feature, you can generate a public and private key pair
with. the Generate X.509 Certificate button. If you do this, you must down
load the private key (or key pair) and install it into your client application.
SuccessFactors HCM Suite will keep a copy of the private key.
Generate X.509 Certificate Button A button that generates a X.509 certificate if the customer doesn't have one
already. When clicked, a dialog box is displayed, in which the customer can
enter the following information then click "Generate" to generate a self-
signed certificate:
Common Name: The name or IP address for which the certificate is valid.
Organization Unit: (optional) The organization unit of the entity to which the
certificate is issued.
Validity: The number of days for which you want the X.509 certificate to be
valid.
If you have generated the X-509 Certificate, you must download the private key to use it in your client application
to make token requests. The system saves the public key. You will need to regenerate the private key if you lose it.
Note
You will need to save the Private Key before you register you client. Only the Public Key is available for viewing
when the client is registered. You will have the API Key and Private Key available to you in the generated certificate.
You can modify the X 509 certificate and the application description, for an existing client application by clicking
the Edit button for the client application on the application list page. In the client application edit page that
appears, you can make the modifications.
You can either replace the existing X.509 certificate, or regenerate the certificate by clicking the Generate X.509
Certificate button.
You can enable or disable an existing OAuth 2 client by clicking the Disable (Enable) button on the client button for
the client application on the application list page
The SF OData API supports 2-legged authentication for OAuth 2.0. Users with valid accounts in a registered client
can use the SuccessFactors OData API after receiving an OAuth 2.0 token to use in subsequent API calls.
Table 400:
API DESCRIPTION AND USAGE
API for Requesting a User Token Using SAML Assertion Request a Token. A signed SAML Assertion identifying a SAML
IDP and the user must be provided because a request parame
ter acts as a SAML service provider for the client’s SAML IDP.
Access OData API Access OData API with the generated Bearer authorization to
ken.
The following are the APIs for generating a Security Assertion Markup Language (SAML) assertion for
authentication.
Table 401:
RESOURCE DESCRIPTION
PARAMETERS ● client_id - OAuth client id. This is the API Key that was generated earlier.
● user_id - NameId in the SAML assertion.
● token_url – Recipient in SAML assertion.
● private_key – used to sign SAML assertion.
● use_email (optional) - accept "nameid-format:emailAddress" in saml assertion
(b1511 and after)
When "use_email=true" appears in the /oauth/idp request payload, the subject name id format in the generated
saml assertion will now change from "nameid-format:unspecified" to "nameid-format:email". An email address has
to be mapped to a unique BizX user. If such email can be mapped to more than one BizX userId, a HTTP 401 error
(“Unable to map xxx@xxx.xxx to a valid BizX User ID”) will be returned.
Table 402:
RESOURCE DESCRIPTION
DESCRIPTION Issues an OAuth 2.0 token for the user given by the supplied
scope. An error is returned if the user is not found.
RESPONSE BODY Contains the access token that you use in subsequent API
calls:
● An OAuth 2.0 token for the given user. This token must be
used in the “Authorization” header in all subsequent re
quests. Described as below:
○ access_token: a valid OAuth access token.
○ token_type: "Bearer" (this is the only supported
type).
○ expires_in: Remaining lifetime of the access token in
seconds.
MIICDTCCAXagAwIBAgIETJj9LjANBgkqhkiG9w0BAQUFADBLMQswCQYDVQQGEwJVUzEbMBkGA1UE
ChMSU3VjY2Vzc2ZhY3RvcnMuY29tMQwwCgYDVQQLEwNPcHMxETAPBgNVBAMTCFNGIEFkbWluMB4X
DTEwMDkyMTE4NDUwMloXDTI1MDkxOTE4NDUwMlowSzELMAkGA1UEBhMCVVMxGzAZBgNVBAoTElN1
Y2Nlc3NmYWN0b3JzLmNvbTEMMAoGA1UECxMDT3BzMREwDwYDVQQDEwhTRiBBZG1pbjCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEArA9RLNnL9Pt6xynFfYfa8VXAXFDG9Y8xkgs3lhIOlsjqEYwb
SoghiqJIJvfYM45kx3aB7ZrN96tAR5uUupEsu/GcS6ACxhfruW+BY6uw8v6/
w2vXhBdfFjBoO+Ke
Lx4k3llleVgKsmNlf81okOXv1ree8wErfZ3ssnNxkuQgGB0CAwEAATANBgkqhkiG9w0BAQUFAAOB
gQBeBCSMFnY8TB6jtWoSP/lorBudhptgvO7/3r+l/QK0hdk6CVv
+VQmSilNPgWVgU9ktZGbNkZhw
IgwnqIQHAi6631ufkYQJB+48YUe1q/pv6EWaeIwGvcGYSXZp/E/
aGZPtceTIXFPfqOyHQoFtb0nq
MMFWoDhpXUHmlroyTc9sJg==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:unspecified">star</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData
NotOnOrAfter="2013-10-22T05:46:32.627Z" Recipient="http://
qacandsfapi/oauth/token" />
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2013-10-22T05:26:32.627Z"
NotOnOrAfter="2013-10-22T05:46:32.627Z">
<saml2:AudienceRestriction>
Table 403:
RESOURCE DESCRIPTION
DESCRIPTION Validates a given SAML token for the user given by the sup
plied scope. An error is returned if the user is not found.
RESPONSE BODY Contains an access token, token type, and expiry information
if the token is valid. Described as below::
Note
Please don't use SOAP APIs or Ad hoc APIs for building new integrations in Employee Central. The only
exception to this rule is the SOAP based Compound Employee API (CE API).
UI consumption Yes No
Sometimes a system is changed in a way that leads to an API breaking. More often than not, such incompatible
changes are made during configuration of the system and not by the API consumers. Take a look at this list to see
what actions could lead to an incompatible change - by avoiding these actions in the first place, you should be free
of incompatible changes in your system.
● Removing any field that is exposed by an API from the MDF object definition or HRIS succession data model
will break that API
● Changing the visibility of any field that is exposed by an API in the MDF object definition or HRIS succession
data model from visible/enabled to invisible/none will break that API
● Removing permissions or provisioning settings for OData APIs will break the API
● Renaming the identifier of customString field in the succession datamodel - this breaks the API because
technically what is actually happening is the deletion of the customString field and creation of a new one.
In contrast to these incompatible changes, compatible changes will not break the APIs. Some examples of
compatible changes include:
● Changing the RBP setting for a field from read-only to view not allowed
Upsert statements have a single record error message behavior; for each record that fails, an error message is
issued.
Payload Information:
Sample Code
[
{
"__metadata" : {
"uri" : "https://<Hostname>/odata/v2/
PerPersonal(personIdExternal='aaaa',startDate=datetime'1990-01-01T00:00:00')",
"type" : "SFOData.PerPersonal"
}, "startDate" : "\/Date(631152000000)\/", "personIdExternal" : "aaaa",
"initials" : "LT", "gender" : "M", "namePrefix" : "LT"
}, {
"__metadata" : {
"uri" : "https://<Hostname>/odata/v2/
PerPersonal(personIdExternal='dddd',startDate=datetime'1990-01-01T00:00:00')",
"type" : "SFOData.PerPersonal"
}, "startDate" : "\/Date(631152000000)\/", "personIdExternal" : "dddd",
"initials" : "LT", "gender" : "H", "namePrefix" : "LT"
}, {
"__metadata" : {
"uri" : "https://<Hostname>/odata/v2/
PerPersonal(personIdExternal='hhhh',startDate=datetime'1990-01-01T00:00:00')",
"type" : "SFOData.PerPersonal"
}, "startDate" : "\/Date(631152000000)\/", "personIdExternal" : "hhhh",
"initials" : "LT", "gender" : "M", "namePrefix" : "LT"
}
]
Response:
Sample Code
<feed>
<entry>
<content type="application/xml">
To ignore inactive users in your EC OData API calls, you have to explicitly select them in the User entity using the
property status. Terminated employees will still appear on entities such as PerPerson or EmpJob so the only way
to exclude them is by using the User entity and filtering by the property status which supports the values "t / f / T /
F" or "active / inactive / active_external / inactive_external".
Here are some tips on how to improve API performance and consumption:
Table 405:
Too many deep filters in a query Make sure you are using all the direct available fields in the en
tity
$expand for unnecessary navigations Do you really need those navigations? Are they directly availa
ble fields in the entity.
Merging API calls using navigation (if this is negatively impact Use $BATCH instead
ing performance)
Calculated fields in expanded entities in empCompensation Use rules instead in custom fields to persist the values
Calculated and empCompensationGroupSumCalculated
Writing data using incremental update Use full purge instead, if possible.
Writing data including triggering of rules for job information Disable Triggering of Rules in Company and Logo settings and
(EmpJob) calculate values for rules in consumer.
If you're getting roundtrip errors, this might be down to a conflict between the user locale and the fileLocale.
You can resolve this problem by making sure that your user locale and fileLocale are both en_US. Take a look
atfileLocale [page 53] for more information.
A side effect is sometimes triggered when a consumer performs a write operation; the side effects triggered by the
write operation will be different in the OData API to the side effects triggered in UI. You will find that sometimes the
difference in the side effects is profound - for example a workflow triggered in the UI but not in the OData API. In
other cases, the difference in the side effects is minor such as when an HRIS Sync is triggered directly in the UI but
indirectly in the API/imports indirectly via an asynchronous Sync Job sending e-mails when started and finished.
Take a look a these examples to get an overview of what side effects are triggered when:
● Triggering of business rules: The only OData APIs that trigger business rules are EmpJob and EmpTermination
● Triggering of HRIS Sync: Each upsert on HRIS entities triggers the HRIS sync report as an asynchronous job.
This only happens if no other HRIS sync job is running.
● Triggering of Intelligence Services (Smart Event): Remember that Smart Events are triggered by rules only.
The only entity that can trigger them is EmpJob.
● Triggering of hard coded business logic in Position Management, Global Assignment and Time Off: An
asynchronous process synchronizes Postion and Time-off data in these products and this event is hard-coded
and monitored by provisioning. The only OData API that can trigger this hard-coded business logic is EmpJob.
If you're puzzled by the results you get from queries such as https://<hostname>.com/odata/v2/EmpJob?
$filter=standardHours+gt+'20'&fromDate=2000-12-31, then take a quick look athe examples here $filter
with toDate and fromDate [page 39].
If your're having problems with duplicate records, take a look at these tips.
Picklists
When you use a picklist label (picklistLabels) in a $filter query, specify the locale to avoid duplicate records.
Background: When a picklist has more than one locale and this is not defined in a query, all the locales will be
queried. This could result in duplicate records.
$filter=<entity>Nav/picklistLabels/locale eq 'en_US'
Paging
If pages have duplicates or missing records, one possible reason is undefined sorting. Try using orderBy on the
whole business key to fix this issue.
Coding Samples
Any software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system
environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and
completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP
intentionally or by SAP's gross negligence.
Accessibility
The information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be a
binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however, does
not apply in cases of willful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations of SAP.
Gender-Neutral Language
As far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as "sales
person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun does not
exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible.
Internet Hyperlinks
The SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does not
warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any damages
caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for transparency (see:
http://help.sap.com/disclaimer).