Professional Documents
Culture Documents
1 Change History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Standard Payroll Integration Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Integration via Process Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
5 Appendix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1 Country-Specific Mapping of Address Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Learn about changes to the documentation for Standard Payroll Integration Template for SAP SuccessFactors
Employee Central in recent releases.
1H 2021
2H 2020
The following table summarizes changes to this guide for the 2H 2020
Added a note under Standard Payroll This change is applicable to the 2H 2020 Standard Payroll Integration Template
Integration Template. preview environment only. [page 5]
1H 2020
The following table summarizes changes to this guide for the 1H 2020
This guide is for Professional Services, SAP consultants, and partner consultants to integrate SAP SuccessFactors
Employee Central with any payroll provider.
Integration is through the process library. This is not an out-of-box solution to integrate with any payroll provider.
The process library is a collection of modules (standalone design patterns) that can be used to integrate Employee
Central with payroll providers, with some modifications and manual mapping to achieve the provider-specific
integration use case.
For more information about Employee Central, see the Employee Central Master document https://help.sap.com/
viewer/b14dd15ca58f43e0856184a740a4b212/latest/en-US on SAP Help Portal at https://help.sap.com/viewer/
index → SAP SuccessFactors Employee Central.
Standard payroll integration is a template process with a collection of standalone generic functionalities that can be
used by consultants to build Employee Central integrations with any third-party payroll provider.
This process is to be treated as a template with a collection of generic modules to build a provider-specific
integration process. It is not an executable process. The modules must be chosen based on the provider’s
requirements and with little custom development (like certain provider-specific logic). The process is to be
developed and only then executed. The standard process cannot be consumed directly.
Dell’s Boomi is used as middleware to integrate Employee Central with payroll providers via a CSV file or XML file.
These outbound files (CSV or XML) contain data only for those employees that have undergone a change/
modification in the Employee Central system since the previous execution of the Boomi process. During the initial
run, the process fetches all changes in the system; for subsequent runs, it fetches only the changes since the last
run.
Note
Whenever you run a query using the Compound Employee API, ensure that the timestamp is not older than
three months from the current date. In case, the timestamp is older than three months, an error is logged. This
change is applicable to the 2H 2020 preview environment only.
The outbound file contains only one type of record that comprises the entire employee data.
Note
Separate mapping is required for fields that are country-dependent (for example, Ethnicity). Accommodating
mapping for each country-specific field would not be feasible. Hence, some manual effort is required to adapt
this process to a specific country. As a standard, this process has been adapted to work for the USA.
Use the following steps as a guideline to successfully integrate Employee Central with the payroll provider. This is a
simplified approach to a possible integration process. You have to determine your provider’s business
requirements. Based on their requirements, you will need to adjust these processes.
The replication of employee master data from Employee Central to any payroll provider uses the compound
employee service from Employee Central. The data used for replication contains the following elements.
3.1 Prerequisites
The compound employee API extracts employee data from Employee Central and returns it in a (normalized)
hierarchically structured response XML (root node: employee person data).
Europe https://api.successfactors.eu/sfapi/v1/soap
Get the generic WSDL by adding ?wsdl to the above addresses, for example,
https://api.successfactors.eu/sfapi/v1/soap?wsdl
Apart from the endpoints, an XML schema is provided that describes the XML response of the compound API
including all substructures and elements. The XML schema is required for integration purposes. The new API
provides only the query and the queryMore operation. All other operations such as list, describe, and describeEx
are not supported.
Once a customer opts for a particular third-party payroll provider, the customer should sync on the following points
for initial setup preparations to be done at the third-party provider's end:
• Functional preparation, for example, availability of a document such as Discovery and Requirements Gathering
• Payroll setup
• Technical setup of employee file
• SFTP server configuration
The following tables list the Employee Central fields that are required to replicate data using the Boomi middleware
to any payroll provider. They also show which fields you need to map manually (in the case of country-specific
fields) and the corresponding picklist IDs. You will also find descriptions of the mapping activities that are required
for different fields.
Picklist ID/
Employee Cen Obligatory for Code Mapping Constraint/ Cross-Refer Payroll Provider
tral hris Field Description Replication? Required? Constant Value ence ID Attribute
Marital Status
These values are mapped in Boomi via the cross-reference table Marital Status. This table must be filled by the
consumer based on the Employee Central picklist and the provider’s values. Default mapping values are available.
Gender
These values are mapped in Boomi via the cross-reference table Gender. This table must be filled by the consumer
based on the Employee Central picklist and the provider’s values. Default mapping values are available.
Suffix
These values are mapped in Boomi via the cross-reference table Suffix. This table must be filled by the consumer
based on the Employee Central picklist and the provider’s values. Default mapping values are available.
Salutation
These values are mapped in Boomi via the cross-reference table Salutation. This table must be filled by the
consumer based on the Employee Central picklist and the provider’s values. Default mapping values are available.
Employee Central Obligatory for Code Mapping Re Picklist ID/ Cross- Payroll Provider
hris Field Description Replication quired? Reference ID Attribute
Ethnic Origin
These values are mapped in Boomi via the cross-reference table Ethnicity. This table must be filled by the
consumer based on the picklist and the provider’s values. Default mapping values are available.
Picklist ID/
Employee Cen Obligatory for Code Mapping Constraint Cross-Refer Payroll Provider
tral hris Field Description Replication Required? Value ence ID Attribute
Address Fields
The mapping of the Employee Central fields address1-20 is country-dependent. Based on the country, these fields
are mapped to the appropriate payroll provider attributes. See also Country-Specific Mapping of Address Fields.
For phone Information, a constraint is specified in the Boomi mapping, which transfers the phone information
depending on phone_type.
Picklist ID/
Employee Cen Obligatory for Code Mapping Constraint Cross-Refer Payroll Provider
tral hris Field Description Replication? Required? Value ence ID Attribute
Phone Number
The Employee Central fields area_code and phone_number are mapped to the fields Employee Home Phone,
Employee Personal Mobile Phone, or Employee Business Phone, depending on phone_type, via a build 10-digit
phone number function. This user-defined function builds a 10-digit phone number by using both the area code and
phone number. It does this in the following steps:
1. String Append
Appends the phone number to the area code.
2. String Remove
Removes any unwanted characters.
3. Right Character Trim
Trims the phone number from the right while keeping the length fixed to 10.
For email information, a constraint is specified in Boomi, which transfers the email information depending on
email_type.
A script in the Boomi mapping maps an email address with type P (personal) to Employee Personal Email, and an
email address with type B (business) to Employee Business Email.
The Employee Central field email-address is mapped to the field Employee Personal Email or Employee Business
Email in the provider file, depending on the email address type. The field email-type can have the following values:
• P = personal
• B = business
The Employee Central field lastDateWorked is mapped to the field Last Date Worked in the provider file via a script.
The script populates this value only if the employee is active in the Employee Central system.
Picklist ID/
Employee Cen Obligatory for Code Mapping Constraint/ Cross-Refer Payroll Provider
tral hris Field Description Replication? Required? Constant Value ence ID Attribute
location Location
department Department
division Division
created_on X
company Company
employ Employment
ment_type Type
emplStatus X
event X
• eventReason
• enddate
• emplStatus
This function maps eventReason and endDate directly to Termination Reason and Termination Date if EmplStatus
is T (terminated).
The following Employee Central fields are mapped to the field Event and Event Reason in the provider file via a
scripting function:
• eventReason
• event
• start_date
• created_on
If the created_on timestamp is greater than the last_execution_timestamp, and if the event is H, this function maps
the event directly to Event, and maps eventReason to Event Reason in the provider file.
percentage Percentage
Employee Cen
tral hris Ele Employee Cen Obligatory for Code Mapping Payroll Provider
ment tral hris Field Description Replication? Required? Picklist ID Attribute
The Employee Central field nationalIdCard is mapped to the field Employee Issued Government ID in the provider
file via a filter national ID based on country function. This function maps the national ID card value to the output if
the country of the national ID information is the same as the country specified in the process property extension.
lastName X
isAccompanying Is a Dependent
Dependent
amount Amount/
Percent
The mapping of the Employee Central fields to the third-party provider’s field requirements is done via a Boomi
process. The following section explains how information is mapped from Employee Central to the third-party
payroll provider using Boomi as the middleware.
To achieve this, several modules are provided as subprocesses in Boomi, which can be used in combination to
realize a fully developed Boomi process that addresses the actual use case of sending the Employee Central data to
the provider in an appropriate format.
Main Process: Packaged Integration – Standard Payroll Integration Template
This serves as a basic/standard template for integrating Employee Central with payroll providers.
This process is to be treated as a template that shows the collection of modules (standardized) that can be used
for integration purposes with little or no modification. It calls the following subprocesses:
Subprocess Description
Sub: Extract Employee Central Data Collection of modules that aids in extracting the data from Em
ployee Central
Sub: Transform Employee Central Data Collection of modules that aids in transforming the Employee
Central data and generates different output files
Sub: Write to SFTP Encrypt the data and send the data via SFTP, encryption being
optional
Note
This process shows the logical connection of different modules and should not be executed directly.
Note
The step Retrieve Last Execution Timestamp is very important for the process to run in delta mode. This step
extracts the persisted last execution timestamp and sets it again to the same process property from which it is
retrieved. This is a workaround because any property is persisted at “per process level” according to Boomi.
Therefore, it has to be retrieved in the same process in which it is persisted. Hence, this step allows you to
access the timestamp anywhere across the subprocesses.
Note
As a last step of the main process, the LOCAL_LAST_EXECUTION_TIMESTAMP dynamic process property value
is persisted for use during the next process execution. The timestamp is not persisted if the process is executed
for a particular employee using the employee filter criteria person_id_external. This mode of execution where
the timestamp is not persisted is known as debug mode.
This subprocess shows a collection of modules that aid in transforming the Employee Central data that was
extracted using the subprocess Sub: Extract Employee Central Data. The modules are as follows:
Module Description
Sub: Log Compound Employee API Error Messages Log the compound employee API log messages (if any) for
each employee
Sub: Handling Global Assignments In the case of multiple assignments, split the employee re
sponse based on the assignment and handle each assignment
individually
Sub: Exclude Terminations Exclude only current terminations and allow only future termi
nations
Sub: Generate Flat File Output Use either the normalized data/denormalized data and map
this data to the output flat file profile and also obtain the count
of records generated
Sub: Generate XML Output Use either the normalized data/denormalized data and map
this data to the standard HR XML profile
For the employees extracted from Employee Central, this subprocess obtains their dependents’ information from
the PerPersonRelationship entity. The information obtained is cached for later use in the actual mapping of
employee data.
Sub: Cache for Compound Employee Fixup – Query Foundation Object FO_PayCalendar
This subprocess extracts data from foundation object FO_PayCalendar. Since this information is common across
all employees and specific to any particular employee, it is queried directly. This data is cached for later use in the
actual mapping of employee data.
If the persisted value is not null, set this value to the dynamic process property
LOCAL_LAST_EXECUTION_TIMESTAMP.
If the administrator does not provide this value, then in the worst case, the dynamic process property
LOCAL_LAST_EXECUTION_TIMESTAMP is set to the current timestamp.
Store the execution timestamp returned in the first document of the compound employee response. The logic to
fetch the timestamp from the first document is as follows:
Query compound employee using the dynamic WHERE clause (refer Build Query Filter subprocess) and return the
response as is (in normalized format).
Each compound employee response document is treated by the Groovy script Fix Address, Email & Phone
Types that does the following:
• Checks whether address type home is lower- or uppercase and sets it to lowercase, home .
• Checks whether email types B and P are lower- or uppercase and sets them to uppercase, B and P .
• Checks whether phone types H , B , and C are lower- or uppercase and sets them to uppercase, H , B , and
C.
Each compound employee response document passed into this subprocess is treated by the Groovy script De-
Normalized Dates that converts the compound employee data into a de-normalized snapshot format. Each of these
snapshot documents is then treated by the Groovy script Sanitize Snapshot Data – Remove Unwanted Snapshots
that removes any malformed snapshots that have been created.
In a normalized compound employee response, all data is spread across effective dated entities. In a de-normalized
snapshot response, all effective data is collected and housed under a tag <snapshot>. This tag is created based on
the start_date of each effective dated entity. Its validity is described by a child element <asOfDate>.
Note
Example:
This subprocess builds the WHERE clause that aids in fetching only the current active records of employees in
Employee Central. This is achieved by using the condition effective_end_date = current date in the WHERE clause.
First, it calls the subprocess Sub: Last Execution Timestamp – Initialize to initialize the last execution timestamp.
Next, it checks whether the process property person_id_external is populated. If it is populated, it is appended to
the dynamic process property WHERE along with the condition effective_end_date = current date. It also sets the
dynamic process property DEBUG to True, so that the timestamp in this execution is not persisted.
If the Person ID property is not populated, the following two conditions are appended to the dynamic process
property WHERE:
• effective_end_date=current date
• last_modified_on>last execution timestamp
It also checks for other filter properties. If they are populated, they are appended to the property WHERE.
This subprocess builds the WHERE clause that aids in fetching only the past, current, and futurerecords of
employees in Employee Central. This is achieved by NOT using the condition effective_end_date = current date in
the WHERE clause.
First, it calls the subprocess Sub: Last Execution Timestamp – Initialize to initialize the last execution timestamp.
Next, it checks whether the process property person_id_external is populated. If it is populated, it is appended to
the dynamic process property WHERE. It also sets the dynamic process property DEBUG to True, so that the
timestamp in this execution is not persisted.
If the Person ID property is not populated, the following condition is appended to the dynamic process property
WHERE:
It also checks for other filter properties. If they are populated, they are appended to the property WHERE.
This subprocess builds the WHERE clause that aids in fetching the current and futurereords of employees in
Employee Central. This is achieved by using the condition effective_end_date = current date in the WHERE
clause.
First, it calls the subprocess Sub: Last Execution Timestamp – Initialize to initialize the last execution
timestamp.
Next, it checks whether the process property person_id_external is populated. If it is populated, it is appended to
the dynamic process property WHERE along with the condition effective_end_date = current date . It also sets
the dynamic process property DEBUG to True, so that the timestamp in this execution is not persisted.
If the Person ID property is not populated, the following two conditions are appended to the dynamic process
property WHERE:
It also checks for other filter properties. If they are populated, they are appended to the property WHERE.
This subprocess queries the foundation object Pay Calendar and fetches the current valid calendar for the pay
group specified in the process extensions, and then makes a note of the pay period end date in the dynamic
process property PAYPERIODENDDATE.
Next, it checks whether the property PAYPERIODENDDATE is null or not. If it is null, then in the worst case, the
property value is set to the current date.
Then, it checks whether the process property person_id_external is populated. If it is populated, it is appended to
the dynamic process property WHERE along with the condition effective_end_date = PAYPERIODENDDATE. It also
sets the dynamic process property DEBUG to True, so that the timestamp in this execution is not persisted.
• effective_end_date=PAYPERIODENDDATE
• last_modified_on last execution timestamp
It also checks for other filter properties. If they are populated, they are appended to the property WHERE.
This subprocess logs the compound employee API log messages (if any) for each employee.
This subprocess uses the standard library subprocess Sub: XSL/XPATH Processing v1.1 to filter out the inactive
global assignments based on the condition that is specified using the set properties step. If the document has
multiple employment information, the document is split and all the documents are filtered by the filters set under
the process extension Employee Filter Criteria.
• If it is the first execution of the process, and if the exclude terminations process property is checked, the
terminated employees are removed based on the condition job_info/start_date < current_date .
• If it is not the first execution of the process, or the exclude terminations process property is not checked, the
terminated employee’s record is checked if it is sent at least once to the provider by the condition job_info/
created_on last_execution . If it is not sent at least once, it is sent to the provider; otherwise, it is checked
whether it is a valid termination. For this check there are two conditions: emp_info/payrollEndDate <=
PAYPERIODENDDATE and emp_info/payrollEndDate <= CurrentDate . If the PAYPERIODENDDATE is null, the
latter condition is used; otherwise the former condition is used.
Note
Set the sender and receiver email IDs before attempting to send email notifications.
This subprocess checks for the PGP encryption process property. If it is enabled, the file is encrypted using the
certificate provided in the extension and then written to the remote SFTP location. If the PGP property is not
enabled, the file is written directly to the remote SFTP location without encryption.
This subprocess is used to map the Employee Central data to a pipe-delimited flat file profile and to obtain the
record count.
Note
If any exceptions are caught while mapping the employee data, they are emailed to the administrator.
This subprocess is used to map the Employee Central data to an HR-XML profile.
If any exceptions are caught while mapping the employee data, they are emailed to the administrator.
Note
A process library is a collection of processes published for the purpose of sharing with managed accounts on a per
account group basis. Users of managed accounts install copies of library processes in their accounts and typically
use the installed processes as templates for new processes. These activities take place on the Process Library page
( Manage Process Library ).
This solution, when consumed as a process library, makes the current integration process for standard payroll
available as a process in the process library. This process can then be enhanced further as per the customer's
requirements.
Note
Example
Maintain the connection endpoint details for the system involved in the integration. This helps to send/retrieve data
to/from the appropriate systems.
SF API/OData Connection
Field Entry
Endpoint Datacenter
Username/Password API user and password that have permission to retrieve data
from the API
To configure the process to connect to the provider’s SFTP server, make the following entries:
Field Entry
To configure the process to connect to the provider’s mail/SMTP server, make the following entries:
Field Entry
The process properties contain customizing options. To configure the process properties, you can override the
default values.
General Settings
Property Description
SFTP Remote Directory Directory on the provider server where the file is saved
EC_Standard_Last_Execution_Timestamp Enter the execution timestamp to be used for the first ever exe
cution of the process
To fetch data based on a particular filter, you can change the same under the process properties of the Boomi
process. The following filters are available for the current integration process.
Filter Description
company_territory_code(Country) Provide a single value for the country (ISO-3 code). This field is
mandatory because this process generates an output file spe
cific to a country and also includes this country code in the file
name. If this field is left blank, an email is sent to the adminis
trator and the process is aborted.
Exclude Termination for First Execution of the Process Excludes terminated employees from being entered in the out
bound file during the first execution. Current termination is de
termined based on job_information/start_date.
The cross-reference tables are translation tables between the Employee Central picklist entries and the provider
values. Fill out the cross-reference tables to add or override the existing values.
• Ethnicity
In the first column enter the Employee Central ethnicity code, and in the second column the provider ethnicity.
These values are for the USA and need to be changed according to the country.
• Marital status
In the first column enter the Employee Central marital status code, and in the second column the provider
marital status code.
• Gender
In the first column enter the Employee Central gender code, and in the second column the provider gender
code.
• Suffix
In the first column enter the Employee Central suffix code, and in the second column the provider suffix code.
• Job event
In the first column enter the Employee Central event code, and in the second column the provider event code.
• Timezones
In the first column enter the Employee Central timezone code, and in the second column the provider timezone
code.
• Payment method
In the first column enter the Employee Central payment method code, and in the second column the provider
payment method code.
• Cost center
In the first column enter the Employee Central cost center code, and in the second column the provider cost
center code.
The standard payroll integration template generates a pipe-delimited flat file with a .csv extension. The layout of the
file to be generated can be seen in the sample layout below.
SL. No Fields
1 Person ID
2 Person ID External
3 Payroll Group
4 Payroll Status
9 Employee Salutation
15 Employee Gender
18 Ethnicity Code
45 Dependent Name
46 Dependent Relationship
47 Is a Dependent
48 Payment Method
52 Deposit Type
53 Processing Type
54 Amount/Percent
58 Company
59 Business Unit
60 Division
61 Department
62 Location
63 Timezone
64 Cost Center
65 Employee Status
66 Employee Type
67 FLSA Status
68 Employment Type
69 Employment Status
70 Administrative Category
72 Event
73 Event Reason
74 Payroll Event
75 Shift Code
76 Shift Rate
78 Pay Type
79 Pay Group
80 Payroll ID
83 Pay Component 1
89 Pay Component 2
95 Pay Component 3
250 Percentage 1
252 Percentage 2
254 Percentage 3
256 Percentage 4
264 Employment ID
265 User ID
The standard payroll integration template is a collection of standalone generic functionalities that can be used by
consultants to build Employee Central integrations with any third-party payroll provider. The example process
shows how a provider-specific payroll process can be built using the standard payroll integration template.
• The process should fetch the current and future records for an employee who has been modified after the
previous execution of this process, that is, only modified employees are reported.
• The process should generate one flat file as an output with all information for an employee. For the layout of the
output file, see Output File Layout .
• The process should be able to handle global assignments, that is, the employee information has to be spilt
based on the employment information using country filter and reported for the country specified in the process
property.
• The process should exclude terminated employees in the output file generated.
• The process should send a mail to the recipient (admin) on the status of the process.
• The process should encrypt the output file via PGP and place it in the SFTP location specified in the process
properties.
4.2 Implementation
• Obtain the standard payroll integration template from the process library to your Boomi account. See Getting
Access to the .
• Navigate to the main process and remove the subprocesses that are not required (as per the above
requirements). For information about the collection of subprocesses available in the main canvas, see
Integration Process Overview .
• Based on the above requirements, the following modules are relevant and are kept in the final process.
• Subprocess Extract:
• Main Process
For address information, the mapping between Employee Central hris fields and payroll provider attributes is highly
dependent on the address country. Based on the address country, the Employee Central fields are mapped to the
appropriate payroll provider attributes.
The following tables show the mapping between the Employee Central hris fields and the payroll provider attributes
based on country.
Payroll Provider
Attribute Argentina Australia Austria Belgium Brazil
Home Address - - - - -
Care Of Name
Home Address - - - - -
Room ID
Home Address - - - - -
Building ID
Home Address - - - - -
Street Prefix Name
Payroll Provider
Attribute Bulgaria Canada Chile China Colombia
Home Address - - - - -
Room ID
Home Address - - - - -
Floor ID
Home Address - - - - -
Building ID
Home Address - - - - -
Street Prefix Name
Home Address - - - - -
Room ID
Home Address - - - - -
Floor ID
Home Address - - - - -
Building ID
Home Address - - - - -
Street Prefix Name
Payroll Provider
Attribute Germany Greece Guatemala Honduras Hong Kong
Home Address - - - - -
Room ID
Home Address - - - - -
Floor ID
Home Address - - - - -
Building ID
Payroll Provider
Attribute Hungary India Indonesia Ireland Israel
Home Address - - - - -
Room ID
Home Address - - - - -
Room ID
Home Address - - - - -
Floor ID
Home Address - - - - -
Street Prefix Name
Payroll Provider
Attribute Netherlands New Zealand Norway Pakistan Panama
Home Address - - - - -
Room ID
Home Address - - - - -
Floor ID
Home Address - - - - -
Building ID
Home Address - - - - -
Street Prefix Name
Payroll Provider
Attribute Slovenia South Africa South Sudan Spain Sweden
Home Address - - - - -
Room ID
Home Address - - - - -
Floor ID
Payroll Provider
Attribute Switzerland Taiwan Thailand Turkey Ukraine
Home Address - - - - -
Room ID
** The standard implementation provides country-dependent address mapping for the countries listed in the above
tables. For all other countries, the DEFAULT mapping is used.
Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:
• Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your agreements
with SAP) to this:
• The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
• SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
• Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such links, you
agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this information.
Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax and
phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of example
code unless damages have been caused by SAP's gross negligence or willful misconduct.
Bias-Free Language
SAP supports a culture of diversity and inclusion. Whenever possible, we use unbiased language in our documentation to refer to people of all cultures, ethnicities, genders,
and abilities.
SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.