SAP NetWeaver

How-To Guide

How to Create a New Event for

eSocial

Applicable Releases:
SAP_HR 6.00 and higher

Version 2.0
October 2017
 Copyright 2012 SAP AG or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission
of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software
vendors.
National product specifications may vary.
These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without
representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials.
The only warranties for SAP Group products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered
trademarks of SAP AG in Germany and other countries. Please see http://www.sap.com/corporate-
en/legal/copyright/index.epx#trademark for additional trademark information and notices.

SAP NetWeaver How-to Guides are intended to simplify the product implementation. While specific product features and
procedures typically are explained in a practical business context, it is not implied that those features and procedures are the
only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional
information, clarification or support, please refer to SAP Consulting.
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 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, except if such damages were caused by SAP
intentionally or grossly negligent.

Disclaimer:
Some components of this product are based on Java. Any code change in these components may cause unpredictable and
severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components.
Any Java Source Code delivered with this product is only to be used by SAPs Support Services and may not be modified or
altered in any way.

i
Document History

Document Version Description

1.0 Initial version.
1.1 Background diagrams updated. Customizing table for customer. New event
classification. Change Manager information added to appendix.
1.2 Header fields of the XML.
1.3 Information about generators report. Table events generated monthly. New
way to instantiate the event.
1.4 New interface information. Information about the Data Viewer and Monitor.
1.5 Redesign of technical background and news of the latest releases.
1.6 Information about Deadline calculation and information about data structures.
1.7 More information about tables and structures. More information about the
obsolete status.
1.8 New ABAP OO interface. eSocial Framework Components diagram updated.
New event status. New report for fixing events. List of data dictionary
structures of events which the data extraction is not in the standard.
1.9 eSocial Framework Components diagram updated. eSocial flows updated.
2.0 Change Manager information updated. Information about the XML generation
classes.

ii
Typographic Conventions Icons

Type Style Description Icon Description

Example Text Words or characters quoted Caution
from the screen. These
include field names, screen Important
titles, pushbuttons labels, Note
menu names, menu paths,
and menu options. Recommendation or Tip
Cross-references to other
documentation Example

Example text Emphasized words or

phrases in body text, graphic
titles, and table titles
Example text File and directory names and
their paths, messages,
names of variables and
parameters, source text, and
names of installation,
upgrade and database tools.
Example text User entry texts. These are
words or characters that you
enter in the system exactly as
they appear in the
documentation.
<Example Variable user entry. Angle
text> brackets indicate that you
replace these words and
characters with appropriate
entries to make entries in the
system.
EXAMPLE TEXT Keys on the keyboard, for
example, F2 or ENTER.

iii
Table of Contents
1. Business Background .....................................................................................................1
2. Technical Background ....................................................................................................1
2.1 eSocial Framework Components...............................................................................1
2.2 eSocial Framework Details........................................................................................3
2.2.1 ABAP OO Interfaces .....................................................................................4
2.2.2 Processing class...........................................................................................5
2.2.3 Data storage .................................................................................................5
2.2.4 Event Data Structures ...................................................................................5
2.2.5 Customizing..................................................................................................7
2.2.6 Event Deadline .............................................................................................7
2.2.7 Event statuses ..............................................................................................7
2.2.8 Data Selection ..............................................................................................9
2.2.9 Reports....................................................................................................... 10
3. How to Create a New Event for eSocial ........................................................................ 11
3.1 Create the processing class of the event ................................................................. 11
3.2 Customize the eSocial information type table .......................................................... 11
3.3 Define the eSocial application tables ....................................................................... 11
3.4 Create a data structure ........................................................................................... 12
3.5 Implement the processing class .............................................................................. 13
3.6 Customize the events deadline table rules .............................................................. 14
3.7 Customize the eSocial event type table ................................................................... 15
3.8 Customize the eSocial table for Change Manager ................................................... 16
4. Appendix........................................................................................................................ 18
4.1 Appendix A Objects reference .............................................................................. 18
4.2 Appendix B Example of processing class implementation ..................................... 18
4.3 Appendix C Example of logging errors.................................................................. 22
4.4 Appendix D Change Manager .............................................................................. 22
4.4.1 Change Manager for Table Events.............................................................. 23
4.4.2 Change Manager for Employee Events ....................................................... 24
4.4.3 Change Manager for Deletion Events.......................................................... 25
4.4.4 Change Manager for Employee events without rectification ......................... 25
4.4.5 Change Manager for Periodic events .......................................................... 25
4.4.6 Change Manager for Periodic events on employer level .............................. 26
4.5 Appendix E When a new version of the class is necessary ................................... 26
4.6 Appendix F HCM Objects ..................................................................................... 27
4.7 Appendix G Data Dictionary Structures ................................................................ 28
4.8 Appendix H XML Generation Classes .................................................................. 28

iv
1. Business Background

eSocial is a system for digital bookkeeping of payroll, and of work, tax and social insurance tributes,
valid for all employment contracts established in Brazil. Employers must send information about all
employees to the relevant government authorities in a specific timeframe. The information sent to the
government is grouped in events, such as hiring, firing or leave notice.

The events are grouped in three main categories by the Government:

Table events: are the events related to company settings, like wage types, branches, positions,
etc.
Employee events: are the events related to the employee work like, such as: hiring, firing,
absences, dismissal protections, etc. In the new versions of the eSocial manual employee events
are called as non-periodic events.
Periodic events: are the events related to payroll, which have monthly frequency.

REMARK
Note that according to the eSocials layout, the validity of the table events are competence
(month and year) and it does not take account the day. As the SAP tables have begin and end
dates, in case an entry starts and ends in the same month it has to be discarded. The Business
classes of the event are in charge of applying this rule. Use of the standard classes for
reference.

2. Technical Background

The eSocial framework manages the process of extracting the data, storing the data and generating the
XML files to be sent to the government.

The logic to get the data from the database is managed by specific business logic classes, and each
event type has its own class.

The eSocial framework executes the processing of each event and, manages data events
rectification/deletion/changes, and manages the data returned by the event processing. The processing
of the event is business dependent; therefore each event needs to have a specific class extracting the
data from database.

2.1 eSocial Framework Components

Following is designed the components of the eSocial framework.

Main framework components:

Event Generation: Reports to generate the events.

Event Visualization: Report to view events already generated.

Events Monitor: Report for monitoring the events status and deadline.

Scheduler: Report to trigger the sending of events to authorities.

Pulling: Report to trigger the check of the processing status the events sent to the authorities.

Dispatcher: it is the component that fires the Data Engine.

Data Engine: main component of the framework that is in charge of the full processing. It is the
entry point to use the framework, in other words, you use this class when you want to run the
eSocial.
 Data Management: it is in charge of storing and reading data from database.

Event Data Extraction Logic: it is the specific logic of the events to extract data from database
and generate the events.

Change Manager: it is in charge of controlling the generation of the events respecting

rectification/exclusion/changing rules of the eSocial. It deals with what were generated by the
business logic and controls what should and what should not be sent to Government. It also
stores a log of the employee master data changes to be able to run the right eSocial events.

2.2 eSocial Framework Details

The flow of the eSocial execution for data extraction is the following:

The flow of the eSocial execution for events send is the following:
2.2.1 ABAP OO Interfaces

The following ABAP OO interfaces are available for eSocial:

IF_HRPAYBR_EFDF_DATA_EXTRACTOR: interface to be implemented by business
classes to extract data from the database.
IF_HRPAYBR_EFDF_XML_GEN: interface to be implemented by each event type in
order to generate and validate the XML.
IF_HRPAYBR_EFDF_DATA_TRANS: interface to be implemented by business classes
to send the events via Web Services using a technology such as Proxies and PI.
IF_HRPAYBR_EFDF_TYPINF_CONV: interface to be implemented for each information
type (employee number, employer, wage type etc.) to define how it must be displayed to
the end user. This interface is also used by the eSocial Events Monitor to convert the user
input into event information type for search mechanism.
IF_HRPAYBR_EFDF_INF_EXTRACTOR: interface to deal with information values. The
Change Manager component evaluates the selection class and reads the events that were
already generated in productive mode in the database. There is one method in the
interface which should return the information values which were already processed by the
processing class. The framework calls these methods after the processing method. The
processing class can implement this interface in case:
the event use a non-standard selection class, or
the event use a company selection but generates events by employee, or
the event use an employee selection but generates events by company
IF_HRPAYBR_EFDF_CALC_DDLINE: interface to calculate the deadline date of an
event. You can customize it in the T7BREFD_DDLINE table in case you need different rules
to do a calculation that the customizing in the table do not support.
2.2.2 Processing class

Processing class of the event is the class that contains the business logic to fill the event data. This
class is triggered by the framework according to customizing (see section 3.7). It receives the selection
object as parameter (see section 2.2.8) and, according to this selection; the class has to generate one
or more instances of the CL_HRPAYBR_EFDF_EVENT class. It must use the interface
IF_HRPAYBR_EFDF_DATA_EXTRACTOR.

2.2.3 Data storage

The framework controls the events by the table T7BREFD_EVENT. For each event generated in
productive mode an entry is created in this table and an ID is generated (EVENT_ID) to identify the
event. The main fields of the table are:
Event ID: unique global ID of the event
Event type: event type, link to table T7BREFD_EVTYPE
Status: current status of the event
Information type and value: fields to inform what the content of the event refers to, e.g.
employees, branches, companies
Begin and end dates: valid dates of the event

When the eSocial events are generated, they have to be stored in application data tables to allow
you to send the XML file in a future time. The application tables you created must have all fields
necessary by the event XML file. You can create one or more tables, and each event can have one or
more entries in each table you created.

You can reuse tables that had been created or create new tables in case the existing ones do not have
all the information you need. In case more than one table is needed to store the event data in the
database, you have to create a data dictionary structure which can contain a deep structure with the
table lines needed. If the event data uses just one application table, the data structure of the event can
be the line of the table. Check the section 2.2.4 for more information.

The processing class fills the table fields and returns them to the framework so that the framework
saves them in the database.

2.2.4 Event Data Structures

If you want to generate a complex event, which contains many fields, or it has complex deep structures,
you should group all the tables needed for the event in a dictionary data structure. This structure is
called the main structure of the event, and there are some rules that you need to follow when designing
this structure.

When designing a data structure, take the rules below into consideration:
Two kinds of structures must exist:
o Flat structure: structure that only contains data elements as fields. Flat structures
MUST be lines of eSocial data tables.
o Deep structure: structure that only contains structures and table types as fields.
A parent of an application table is the application table that is on the previous level,
according to the image below:
 Child of A*
Parent A*
Main Structure Child of A*
Deep structure
Child of A and
Parent B*

Deep structure Child of B*

(*) eSocial application tables

The structure can be either a line of an eSocial table (see section 3.3), or have a deep structure with
eSocial table lines inside of it.

Example:
HRPAYBR_EFD_S_PAY_EVENT
EMPLOYEE T7BREFD_EE
PAYROLLS HRPAYBR_EFD_T_PAYROLLS
PAYROLL HRPAYBR_EFD_S_PAYROLL
PAY_DATA T7BREFD_PAYROLL
WAGETYPES HRPAYBR_EFD_T_WAGETYPES
LINE T7BREFD_WTS

In this example, the event consists of employee data, each employee can have several payroll runs,
and each payroll run can have several wage types. Each line in the example corresponds to the
following:
The data structure HRPAYBR_EFD_S_PAY_EVENT is the main structure and it has two fields:
EMPLOYEE and PAYROLLS.
The EMPLOYEE field is the line of the table which stores employee information.
The PAYROLLS field is a table type of HRPAYBR_EFD_S_PAYROLL that is used for organizing
the data. This structure has two fields: PAY_DATA and WAGETYPES.
The PAY_DATA field is the payroll data to be saved in the database.
The WAGETYPES field is a table type of the table which saves the wage type information for the
event.
In this example, LINE (wage type) is a child structure of the PAY_DATA (payroll) structure, and
PAY_DATA is a child structure of the EMPLOYEE structure.

The eSocial framework uses the data structure to save the information in the database. You must follow
some rules when creating a deep data structure:
In case of a table is initial1, it is not saved in the database
In case of a parent table is initial, neither the table nor its children are saved in the database
A structure must only contain tables or table types as fields
The first field of a structure must always be a table
o You can use a dummy table2 if not data is necessary

1
It means that no field in the table has value. It is checked with the ABAP statement IS INITIAL.
2
We consider as dummy table, a table which contain only the mandatory fields of the eSocial
application table
2.2.5 Customizing

The customizing of the event types and the corresponding processing classes are stored in the table
T7BREFD_EVTYPE.

2.2.6 Event Deadline

The deadline of the event is the maximum date that an event must be send to the Government. Each
event type has its own rule.

The event Monitor uses the deadline date of the event in order to help the end user to deliver the events
in time to the authorities.

Perform the customizing of the deadline rules of the event in the table T7BREFD_DDLINE. This table
contains fields, which supports more than 15 different combinations of rules.

2.2.7 Event statuses

 Event type: No need of verification?

Event need verification

0: For verification

1: Ready to send

Event regeneration

7: Processing into
batch

2: Sent

4: Waiting correction

3: Accepted

6: Obsolete

5: Manually canceled

For verification: Initial status, defined when the event is created. It is created automatically.

Ready to send: Set when the event was already checked and it is ok to send. It is fired by the
user.

Processing into batch: Set when the event was selected to be sent and assigned to a batch.

Sent: Set when the event is sent to the component that will fire the WebService. It is fired by the
user.

Accepted: Set when the event was received and it is correct. Status changed automatically when
the Government answer is received.
 Waiting correction: Set when the event was sent and it has an error identified by the
Government. Status changed automatically when the Government answer is received.

Manually Cancelled: Set by the user to stop the event flow.

Obsolete: It is used when the event was already sent to the Government but it was deleted (via
S-3000 event or via deletion on table events) or rectified. The change manager creates a link
between the original event and the deleted/rectified one through the T7BREFD_EVLNK table.
This status is set automatically by the change manager when the deleted/rectified event is
accepted.

2.2.8 Data Selection

Selection class is a class that is in charge of carrying the selection data from the selection screen of
the application that triggers the framework to the processing class of the event. The standard solution
has four classes for selection:

CL_HRPAYBR_EFDF_SELECTION: this class contains basic data, like the start and end selection,
whether the execution is productive or not, whether the application needs a detailed log, and extra
parameters if necessary. This class should be used for generic selection of events.

CL_HRPAYBR_EFDF_EE_SELECTION: it is a subclass of the selection class

(CL_HRPAYBR_EFDF_SELECTION). It adds the capacity to hold employee information (personal
number). This class should be used for employee-based events.

CL_HRPAYBR_EFDF_ER_SELECTION: it is a subclass of the selection class

(CL_HRPAYBR_EFDF_SELECTION). It adds the capacity to hold company information (BUKRS).
This class should be used for employer-based events.

CL_HRPAYBR_EFDF_EVT_SELECTION: it is a subclass of the selection class

(CL_HRPAYBR_EFDF_SELECTION). It adds the capacity to hold event information as a selection
(CL_HRPAYBR_EFDF_EVENT class). It is used by the framework to fire the event S-3000.

Ensure that all the events you generate respect the selection period, otherwise the Change Manager
component could lead to unexpected situations.
Do NOT change the begin and end dates of the selection object.

In case you want to have another selection, you can create your own selection class with your rules as
a sub class of the CL_HRPAYBR_EFDF_SELECTION class. After that, you have to create your own report
to select the data, fill the selection class you created and run the framework (dispatcher).

2.2.9 Reports

Generator reports are used to run the eSocial events, and the framework provides three reports for it:

RPC_PAYBR_EFD_EE_GENERATOR (PC00_M37_EFD_EE_GEN transaction): Used to run

events related to employee like: S-2100, S-2200, S-2400, etc.

RPC_PAYBR_EFD_ER_GENERATOR (PC00_M37_EFD_ER_GEN transaction): Used to run events

related to company, basically the table events like: S-1000, S-1010, etc.

RPC_PAYBR_EFD_PAY_GENERATOR (PC00_M37_EFD_PAY_GEN transaction): Used to run

events related to payroll like S-1200, S-1300.

RPC_PAYBR_EFD_AUTO_EE_GEN (PC00_M37_EFD_AEE_GEN transaction): Used to run events

related to employee using the log generated by the PA30 transaction.

eSocial Data Viewer report (RPUPAYBR_EFD_VIEWER - PC00_M37_EFD_VIEWER transaction): it is

the report which allows the use to view the content data of an event which was already run in productive
mode. It reads the data stored in the eSocial application tables and displays it in an ALV table in the
screen. The ALV table is based on the event data structure. There is no action required here for
displaying a new event.

eSocial Monitor of Events (RPU_PAYBR_EFD_MONITOR - PC00_M37_EFD_MONITOR transaction):

it is the report which will display the events and allow the user the manipulate it. All events customized
in V_T7BREFD_EVTYPE table view will be displayed. There is no action required here for displaying a
new event.

eSocial Employee Events Controller (RPU_PAYBR_EFD_MANAGE_EE_EVT -

PC00_M37_EFD_MNG_EEV transaction): this report is used to fix employee events that are not fixable
using the generator reports. This report has an additional authorization object: P_EFD_DELE.
3. How to Create a New Event for eSocial
Below is an overview of how to create a new event for eSocial:

1. Create the processing class of the event

2. Customize the eSocial information type table
3. Define the eSocial application tables
4. Create a data structure
5. Implement the processing class
6. Customize the events deadline table rule
7. Customize the eSocial event type table
8. Customize the eSocial table for Change Manager

The following sections explain each of those steps in detail.

3.1 Create the processing class of the event

...

1. In transaction SE24, create the processing class that implements interface

IF_HRPAYBR_EFDF_DATA_EXTRACTOR. Create the class as a public class. Note that the
naming convention for SAP is CL_HRPAYBR_EFDE_<free_name>, and that there is no naming
convention for customer classes.
a

3.2 Customize the eSocial information type table

...

The information type table stores the main type of information that the event contains; for example,
employee, wage type, company. The information type identify what is the meaning of the information
value of the event, in other words, the information type field and the information value field represents
the event key. You just need to create it in case you want to store an information value that is different
form the ones already supported.

1. In Customizing for Payroll, choose Payroll: Brazil -> eSocial -> Basic settings -> Set information
types.
2. Fill the following fields:
a. Information type define a code for the information type. Note that the namespaces are
the following:
From 01 to 79: SAP namespace
From 80 to 99: customer namespace
b. Conversion class enter an optional class that can be used for converting the information
type to be displayed in the screen. This class has to implement the
IF_HRPAYBR_EFDF_TYPINF_CONV interface. The eSocial framework calls this class
every time it displays the information value field in the output screen.

3.3 Define the eSocial application tables

...

1. Identify which eSocial application tables are necessary to cover the event data.
 2. If necessary, create new tables following the instructions below. Note that the naming convention
for SAP: T7BREFD_<free name>, and that there is not naming convention for customer tables.
Enter the HRPADBR_EFD_S_APP_KEY_FIELDS structure at the beginning of the table as
.INCLUDE and set as key of the table.
Enter the HRPADBR_EFD_S_APP_OTHER_FIELDS structure as .INCLUDE after the
HRPADBR_EFD_S_APP_KEY_FIELDS include.
Enter delivery class A.
The fields of the structures above are filled by the framework. The other fields of the table have
to be filled by the processing class.
o The following fields of the XML should not be created in the application tables because
they will be controlled by the framework (T7BREFD_EVENT table):
id
tpAmb
procEmi
verProc
o The XML fields related to the period (iniValidade and fimValidade) are controlled by the
framework using the table T7BREFD_DTCTRL. Then if you are creating an event that
contains these fields, add this table to your structure.

Notes
You can omit a field to be displayed by the eSocial viewer 3 by replacing data element of the
field by an incorporated data type.
You can create database views for a table, in case you want to reuse a table in another event,
but you do not need all the fields of the table.
Just do it all the following conditions apply:
o The eSocial is not in productive mode yet
o The field in the table is obsolete and will not be used further
o You make sure this field is not yet filled by the data extract class
SAP ALREADY DELIVERED THE TABLES FOR ALL EVENTS OF THE LAYOUT,
INCLUDING THE EVENTS WHICH SAP DOES NOT SUPPORT THE DATA EXTRACTION.
IN THE APPENDIX THERE ARE THE LIST OF DATA STRUCTURES CREATED FOR EACH
EVENT.

3.4 Create a data structure

...

Design a data structure to contain all the fields necessary in the XML and create the data structure in
the data dictionary considering the rules presented in section 2.2.4.

Notes
For table events4 use the T7BREFD_DTCTRL application table to control the dates of the event,
than the framework will be able to handle the insertion/change/deletion process of this event
types. This table contains the following fields:
o Begin date (BEGDA): represents the begin date of the event.
o End date (ENDDA): represents the end date of the event.

3
eSocial viewer is the functionality that displays the generated event information, and it is used by the
generator reports, the Event Monitor report and the Event view report
4
Table events are defined by the Government as the events of eSocial which reports data related to
tables, like wage type table, branch table, etc.
 o Previous begin date (PREV_BEGDA): represents the begin date of the event which was
already sent to the Government. It will be filled by the framework automatically in case
of a change operation
o Previous end date (PREV_ENDDA): represents the end date of the event which was
already sent to the Government. It will be filled by the framework automatically in case
of a change operation
Do not remove any table or data structure of the main data structure of the event in case of
there is already productive events generated.

Note
SAP ALREADY DELIVERED THE DATA DICTIONARY STRUCTURES FOR ALL EVENTS
OF THE LAYOUT, INCLUDING THE EVENTS WHICH SAP DOES NOT SUPPORT THE
DATA EXTRACTION.

3.5 Implement the processing class

...

1. Implement the processing class that you created in step 3.1. For examples of implementation,
see the appendix A. If necessary, create a constructor method for the class, but without
parameters.

Method CREATE_STRUCTURE
o Return a reference to the data structure that contains all the fields of the event.
o The statement CREATE DATA must be used.

Method PROCESS
o Extract the data from the database and create instances of the class
CL_HRPAYBR_EFDF_EVENT to encapsulate each event.
o The method has to use the selection object IO_SELECTION passed by parameter to
filter the data.
The selection object is filled by the application that executes the eSocial
framework.
To process employee events, use the HCM Objects framework to read
employee information (see appendix D).
The selection object can also contain other parameters that are set in the
application
o Use one of the following three static methods of CL_HRPAYBR_EFDF_EVENT class to
instantiate this class:
NEW_INSTANCE_WITH_COMPANY: used for events related to company
IV_BUKRS: Company code
IV_WERKS and IV_BTRTL: Personnel area and Personnel subarea (if
available)
IV_EVENT_TYPE: The code defined on step 3.7 (see below)
IV_BEGDA and IV_ENDDA: the dates that the event refers to. If the
event contains just one date, like hiring, the event dates (BEGDA and
ENDDA) are the hiring date of the employee. If the event is a table event
which contains start and end dates, these dates have to be used
IV_INF_VALUE: the main information that the event contains; for
example, personal number, CPF document, branch, company,
according to information type returned by the method
 GET_INFORMATION_TYPE. For standard values use a constant of the
IF_HRPAYBR_EFD_CONSTANTS_C interface
IR_DATA: the reference to the data structure that contains the data of
the event, the same one defined on step 3.4.
NEW_INSTANCE_WITH_EE: used for events related to employee
IO_EMPLOYEE: Reference to the employee instance
IV_EVENT_TYPE, IV_BEGDA, IV_ENDDA, IV_INF_VALUE,
IR_DATA: The same as the other method
NEW_INSTANCE_WITH_EVENT: used to instantiate the event class using a line
of the T7BREFD_EVENT table
IS_T7BREFD_EVENT: Line of the T7BREFD_EVENT table
IR_DATA: The same as the other method
o Use the CREATE DATA statement and get its reference to set it in the event class. Do
not use local definition of the structure like DATA or attribute of the class.
SAP recommends calling the CREATE_STRUCTURE method.
o A best practice is to create another method inside the class to fill the fields of the
structure and not do this processing in the PROCESS method.
o Let inside the PROCESS method just the code to create the structure and the event
instance.
o In the class there is no need to deal with rectification process because it will be done
by the framework. Just generate the events according to your database and the
framework will control the deletion, insertion and rectification process.

Method GET_EVENTS
o Return a table with the reference to the events created in the method PROCESS

Method GET_INFORMATION_TYPE
o Need to return the type of information on which the event refers to, for example,
employee, CPF, company. It is used as key for the event and it specifies what kind of
information is stored in the field INF_VALUE of the T7BREFD_EVENT table.
o The returned value can to be one of the standards that are defined in the interface
IF_HRPAYBR_EFD_CONSTANTS_C.

Log errors and warnings by using the instance of the CL_HRPAYBR_EFDF_EVENT class to
append exception and messages from message classes and define if the exception is an error
or warning.

To log general errors and warnings which are not specific from events, use the instance of the
class CL_HRPAYBR_EFDF_DATA_LOG which is passed as parameter to the method.

3.6 Customize the events deadline table rules

The deadline table rule is the table that stores the calculation rules to determine the deadline of the
events generated. It is just necessary to create an entry in this table in case the standard rules do not
support the rules of the event you are implemented or in case you want to define a rule with different
deadline to follow different processes in your company.
 1. In Customizing for Payroll, choose Payroll: Brazil -> eSocial -> Basic settings -> Create rules for
transmission of events.
2. Fill the following fields:
a. Rule code define a code for the rule. Note that the namespaces are the following
i. From 0001 to 8999: SAP namespace
ii. From 9000 to 9999: Customer namespace
iii. As this field is a character field, customers can create own values with Yxxx and
Zxxx namespace
b. Description name of the rule
c. Rule type define a type for the rule calculation. The values can be:
i. 1 (After): it will calculate the deadline after a specific date
ii. 2 (Before): it will calculate the deadline before a specific date
iii. 3 (Next Month): it will calculate the deadline as a date in the next month considering
a specific date
d. Field define which field must be used to calculate the deadline. The values can be:
i. 1 Begin date of the event
ii. 2 End date of the event
iii. 3 eSocial starting date
e. Number of days define the number of days to compose the rule calculation
f. Class for rule you can also define a class to calculate the deadline. The class you
customize here must implements the interface IF_HRPAYBR_EFDF_CALC_DDLINE
i.Note that the naming convention for SAP is CL_HRPAYBR_EFDD_<free_name>,
and that there is no naming convention for customer classes.
g. Working days define if the calculation of the deadline must consider just working days,
it means that the deadline of an event will be calculated to be always a working day

Notes
The combination of the fields Rule type, Field, Number of days and Working days define the
rule to calculate the deadline
The Class for rule is just needed in case the customizing of the fields Rule type, Field, Number
of days and Working days is not enough to support a specific requirement for calculating the
deadline of an event

3.7 Customize the eSocial event type table

...

The event type table is the table that stores the event types that can be executed by the framework. It
mainly identifies an event type as a numerical code, and it stores the name of the class that processes
the event (the class created in step 3.1).

1. In Customizing for Payroll, choose Payroll: Brazil -> eSocial -> Basic settings -> Set event types.
a. In this step, you can see the standard entries (V_T7BREFD_EVTYPE table view) and the
customer entries (V_T7BREFD_EVTY_C table view) where you can use to overwrite a
standard entry.
2. Fill the following fields:
a. Event type define a code for the event. Note that the namespaces are the following:
i. From 0001 to 7999: SAP namespace
ii. From 8000 to 9999: customer namespace
b. Start and end dates
c. Processing class enter a class that you created in step 3.1.
 d. Classification The classification is used by the change manager module in order to
decide which rule apply to generate the rectifications, modifications and deletions. There
are 8 possible values:
i. P (Payroll events Periodic events): events which will contain payroll information,
e.g. S-1200 (employee remuneration)
ii. T (Table events): events which will contain data related to company customizing,
e.g. S-1000 (employer/taxable person information), S-1010 (wage types table).
iii. W (Employee events Non-periodic events): events which will contain employee
master data, e.g. S-2200 (employee hiring), S-2005 (change to employee
registration data).
iv. D (Delete events): this is used for the event S-3000 (deletion of events)
v. M (Table event on employee level): events that are table related (defined by the
eSocial) and are processed on employee level, e. g. event type 0006 (S-1030
positions/public positions table). If the event type has this classification it will be
processed by PNP.
vi. E (Periodic event on employer level): events that are periodic (defined by the
eSocial) and are processed on company level, it means that these events will be
executed by company and not by employee as the events S-1200 (employee
remuneration) and S-1300 (union dues).
vii. R (Employee events without rectification): events related to employee that does not
have rectification rule, e.g. S-2190 (employee hiring - preliminary registration).
viii. Q (Periodic event on employer level without rectification): events that are periodic
(defined by the eSocial) and are processed on company level and the event does
not have rectification, e.g. S-1295 (sum of contingency payment).
e. Visualization there are 2 possible values:
i. Detailed: display the event data in the log in a detailed mode, respecting the table
which it is stored.
ii. Flat: display the all the event data in the log in a flat structure, it means,
concatenates all the tables of the event in one single data structure.
f. Event legal code legal code of the event, e.g. S-1000
g. Deadline rule Fill this field for defining the rule to calculate the deadline of the event.
This information is mandatory for the event generation. This rule must be one of the rules
defined in step 3.6
h. Skip For Verification Status indicate that the framework should skip this status to
generate the event. It will generate the event with initial status equals to Ready to send.
i. Maximum number of events per batch indicate the maximum number of events that
should be included in each batch
j. Transmission class enter the name of the class used to send the events to eSocial. By
default, SAP delivers the class configured to send events with SOA Manager:
CL_HRPAYBR_EFDT_SOAM_GEN_01.
k. XML generation class enter the name of the class used to generated the XML of the
event. By default, SAP delivers the classes for all events defined in the eSocial layout
(check the appendix for more information).

3.8 Customize the eSocial table for Change Manager

In case the event type relates to a worker event, you can customize the infotypes that are relevant for
the event and needs to be logged for controlling the regeneration of events.

1. In Customizing for Payroll, choose Payroll: Brazil -> eSocial -> Basic settings -> Set infotypes
relevant for events.
2. Fill the following fields:
a. Infotype: number of the infotype which is relevant for the event.
b. Subtype: code of the subtype of the infotype which is relevant for the event. You can use
the character * to represent any subtype.
c. Field: name of the field of the infotype which is relevant for the event. You can use the
character * to represent any field.
d. Start and end dates
4. Appendix

4.1 Appendix A Objects reference

Object
T7BREFD_EEINFO
HRPADBR_EFDE_S_EMPLOYER_INFO
HRPADBR_EFDE_S_EE_HIRING
CL_HRPAYBR_EFDE_EMPLOYER
CL_HRPAYBR_EFDE_EE_HIRING
CL_HRPAYBR_EFDD_TERM_DEADLINE
Description
Application table with employee information
Data structure of table event
Data structure of employee event
Processing class of table event
Processing class of employee event
Deadline calculation class

4.2 Appendix B Example of processing class

implementation

Method CREATE_STRUCTURE
METHOD if_hrpaybr_efdf_data_extractor~create_structure.
CREATE DATA rr_data TYPE <data_structure>.
ENDMETHOD.

Method GET_EVENTS
METHOD if_hrpaybr_efdf_data_extractor~get_events.
et_events = mt_events.
ENDMETHOD.

Method GET_INFORMATION_TYPE
METHOD if_hrpaybr_efdf_data_extractor~get_information_type.
rv_information_type = if_hrpaybr_efd_constants_c=>
gc_information_type_employee.
ENDMETHOD.

Method PROCESS
Example of implementation using default selection
METHOD if_hrpaybr_efdf_data_extractor~process.

DATA lr_data TYPE REF TO <structure of the event>.

DATA lo_event TYPE REF TO cl_hrpaybr_efdf_event.
 lr_data ?= me->if_hrpaybr_efdf_data_extractor~create_structure( ).

* Fill the fields according to business rule

me->fill_fields( CHANGING cs_data = lr_data->* ).

* Create the event instance

lo_event = cl_hrpaybr_efdf_event=>new_instance_with_company(
iv_bukrs = <lv_bukrs>
iv_event_type = if_hrpaybr_efd_constants_c=>gc_event_type_employer
iv_begda = <date>
iv_endda = <date>
iv_inf_value = <inf_value>
ir_data = lr_data ).

* Store the event in a instance table

APPEND lo_event TO mt_events.

ENDMETHOD.

Example of implementation with employee selection

METHOD if_hrpaybr_efdf_data_extractor~process.

DATA lv_pernr TYPE pernr_d.

DATA lt_pernr_table TYPE hrpay99_pernr_table.
DATA lr_data TYPE REF TO <structure of the event>.
DATA lo_event TYPE REF TO cl_hrpaybr_efdf_event.
DATA lo_ee_selection TYPE REF TO cl_hrpaybr_efdf_ee_selection.
DATA lo_employee TYPE REF TO cl_hrpadbr_employee.

* Cast the selection to work with employees

lo_ee_selection ?= io_selection.

lo_ee_selection->get_pernr_table(
IMPORTING
et_pernr_table = lt_pernr_table ).

LOOP AT lt_pernr_table INTO lv_pernr.

lr_data ?= me->if_hrpaybr_efdf_data_extractor~create_structure( ).

lo_employee = lo_ee_selection->create_employee_instance( ).

* Fill the fields according to business rule

me->fill_fields(
EXPORTING
io_employee = lo_employee
CHANGING
cs_data = lr_data->* ).
 * Create the event instance
TRY .
lo_event = cl_hrpaybr_efdf_event=>new_instance_with_ee(
io_employee = lo_employee
iv_event_type =
if_hrpaybr_efd_constants_c=>gc_event_type_initial_reg
iv_begda = <date>
iv_endda = <date>
iv_inf_value = lv_pernr
ir_data = lr_data ).
CATCH cx_hrpaybr_infty_not_found .
CONTINUE.
ENDTRY .

* Store the event in a instance table

APPEND lo_event TO mt_events.

ENDLOOP.

ENDMETHOD.

Example of implementation with employee selection grouping by CPF document

Define an internal table with CPF and EVENT as fields, like:

TYPES: BEGIN OF gty_s_cpf_event,
cpf TYPE pbr_cpfnr,
event TYPE REF TO cl_hrpaybr_efdf_event,
END OF gty_s_cpf_event.

Method source code

METHOD if_hrpaybr_efdf_data_extractor~process.

DATA lv_pernr TYPE pernr_d.

DATA lv_cpf TYPE pbr_cpfnr.
DATA ls_cpf_event TYPE gty_s_cpf_event.
DATA lt_pernr_table TYPE hrpay99_pernr_table.
DATA lr_data TYPE REF TO <structure of the event>.
DATA lo_event TYPE REF TO cl_hrpaybr_efdf_event.
DATA lo_ee_selection TYPE REF TO cl_hrpaybr_efdf_ee_selection.
DATA lo_employee TYPE REF TO cl_hrpadbr_employee.
DATA lo_master_data TYPE REF TO cl_hrpadbr_master_data.

* Cast the selection to work with employees

lo_ee_selection ?= io_selection.

lo_ee_selection->get_pernr_table(
IMPORTING
 et_pernr_table = lt_pernr_table ).

LOOP AT lt_pernr_table INTO lv_pernr.

lo_employee = lo_ee_selection->create_employee_instance( ).

lo_master_data = lo_employee->get_master_data( ).

lv_cpf = lo_master_data->get_cpf( ).

* Instance attribute table with CPF and EVENT as fields

READ TABLE mth_cpf_event INTO ls_cpf_event WITH KEY cpf = lv_cpf.

IF ( sy-subrc <> 0 ).

lr_data ?= me->if_hrpaybr_efdf_data_extractor~create_structure( ).

* Create the event instance

lo_event = cl_hrpaybr_efdf_event=>new_instance_with_ee(
io_employee = lo_employee
iv_event_type = if_hrpaybr_efd_constants_c=>gc_event_type_initial_reg
iv_begda = <date>
iv_endda = <date>
iv_inf_value = lv_cpf
ir_data = lr_data ).

ls_cpf_event-cpf = lv_cpf.
ls_cpf_event-event = lo_event.

* Store the event in a instance table

APPEND ls_cpf_event TO mt_cpf_events.

ELSE.

lr_data = ls_cpf_event-event->get_date( ).

ENDIF.

* Fill the fields according to business rule

me->fill_fields(
EXPORTING
io_employee = lo_employee
CHANGING
cs_data = lr_data->* ).

ENDLOOP.

ENDMETHOD.
4.3 Appendix C Example of logging errors

1. Using the instance of the class CL_HRPAYBR_EFDF_EVENT.

CATCH cx_hrpadbr_infty_not_found INTO lx_exception.

io_event->append_exception( EXPORTING io_exception = lx_exception
iv_msgty = 'E' ).

2. General errors.

IF lv_ctps_nr IS INITIAL OR lv_ctps_serie IS INITIAL OR

lv_ctps_uf IS INITIAL.

lv_msg_var2 = text-t03.

io_event->append_message(
EXPORTING
iv_message_id = 'HRPAYBR_EFD'
iv_message_type = 'E'
iv_message_number = '001'
iv_message_var1 = lc_record
iv_message_var2 = lv_msg_var2 ).
RETURN.
ENDIF.

4.4 Appendix D Change Manager

The Change Manager is the framework component that deals with the rectification, deletion and change
of events. Before using the Change Manager functionality, make sure that the Business Extractor Class
generates the events using valid data.

For example:
You create an absence infotype for an employee.
When you run the Change Manager framework selecting the employee and the absence period,
the business class generates an event for the absence infotype.
If you delete the absence infotype and run again the business class, the event for the absence
infotype will not be generated, therefore the Change Manager framework will identify that the
event for that absence was deleted.

The Change Manager identifies if an event had a change in its data and generates a rectification for this
change. In other words, when the business class generates an event, the Change Manager evaluates
the content of this event (data) to check if the event was already sent to eSocial national environment,
and performs the following actions:
Sends the event as insertion if it was not sent yet.
Sends the event as change/rectification if the event was already sent with different data.
Discards the event generated by the business class if the event was already sent with the same
data.
Generates a deletion event.
The Change Manager works differently for table events and employee events.

4.4.1 Change Manager for Table Events

Table events cannot be rectified; they can just be changed and deleted.

This rule is used for events with the following classifications:

T (Table events)
M (Table events on employee level)

The business class generates an event for each table entry and delimitation, and the Change Manager
evaluates one-by-one to decide which event must be executed.

Situation System reaction/Comments/Response

You run for the very first time the data
extraction for an event type in
productive mode.
Before sending the generated events,
you run again the data extraction for an
event type in productive mode.
After sending and having all the
generated events accepted, you
change an entry in a table that is
relevant for the event and run again the
data extraction for the event type in
productive mode.
Then, you delete a table entry which is
relevant for the event and run again the
data extraction for the event type in
productive mode.
All the events generated by the business class will be
saved in the database5 with insertion operation.
All the events generated by the business class will be
saved in the database. The events that already existed 6 will
be replaced, the new ones will be created and the ones
which were not generated by this execution will be
deleted7.
The business class generates all the events considering
the table entries. The Change Manager will discard all the
events that were generated with the same content as the
one that was already sent. The event that has a change in
its content will be saved in the database with change
operation.
The process is similar to the one described above, but in
this case the Change Manager will identify that you have
already sent to the eSocial national environment an event
that was not generated now by the business class.
Then, the Change Manager generates automatically an
event with deletion operation, in order to delete from the
eSocial server the event that you have sent before. The
deletion event (which was generated by the Change
Manager) and the original event are automatically linked.
Therefore, you can easily identify that you have sent an
event to the eSocial national environment and now you can
delete it. After the deletion event is sent and accepted, the
original event is set to obsolete status.

5
The database here is the table of the event which is managed by the Data Manager component of the
Change Manager framework.
6
To identify the table event in the database, the following fields are considered as key of the event:
Event Type, Information Type, Information Value, Begin date, End Date.
7
The Change Manager evaluates the selection period of the selection screen of the generation in order
to select the events which were already generated in the database.
4.4.2 Change Manager for Employee Events

Employee events can be rectified. The rectification is basically the resending of an event, and the
exclusion of the first event you sent is done via the event S-3000. That is, to delete an employee event,
you have to send a S-3000 event referring the event you want to delete.

This rule is used for events with classification W (employee events Non-periodic events).

The Change Manager processes employee events similarly to how it processes Table Events, except
for the following scenarios:

For deletion8 of events, the event S-30009 is automatically generated instead of sending the
same event with a deletion operation.

For rectification of events:

o The Change Manager searches for an event in the database with the following criteria:
Event type
Information Type
Information Value
Begin date
End Date
o In case the event is not found, the Change Manager searches for an event considering
the following criteria:
Event type
Information type
Information value
Begin date from the selection screen
End date from the selection screen
o The rectification of an event is necessary in order to identify correctly the event in the
database when an employee had an infotype with dates changed.
o The rectification of an event is a new event that is generated and linked to the original
one.

Find below examples of the Change Manager behavior using an infotype as reference to generate the
event S-2205 (change to employee registration data).

Situation System reaction/Comments/Response

You have created an infotype entry and ran
the generation report for the event S-2205.
You sent the event to eSocial and had it
accepted in the system.
You have changed the infotype entry that
you created before.
You sent the event to eSocial and have it
accepted in the system.
The system generates the event as insertion.
This step is done by other eSocial components.
The system generates a new event defining it as a
rectification of the original event, and creates a link
between the two events.
When the rectification event is accepted, the original
event is set to obsolete status.

8
By deletion here, it is understood an event that exists in the database for the selection period but that
was not generated in the current execution by the business class.
9
The event S-3000 cannot be generated using the standard generation reports.
4.4.2.1 Change Manager on Master Data

For employee events, there is also the possibility to customize an eSocial table to register a log of the
master data changes that are relevant for the eSocial. This procedure is useful to identify which events
should be regenerated for each employee.

The Tabela de controle de eventos para serem gerados (T7BREFD_EVTOGEN) table stores the infotype
log. This table is maintained by the Change Manager framework and stores:
Personal Number
Event type: The code of the event that needs to be generated
Begin and end dates

The customizing is done in the Campos de Infotipos relevantes para gerao de eventos
(T7BREFD_ITEVTRIG) table, as explained in the steps to create an event.

4.4.3 Change Manager for Deletion Events

The deletion event (S-3000) cannot be deleted and rectified, that is, this type of event only generates
insertions. This rule is applied to events with the classification D (Deletion events).

When the deletion event (S-3000) is generated, it is automatically linked to the event that should be
deleted. After the deletion event is sent and accepted by the eSocial, the original event (the one to which
it is linked) is set to status obsolete.

4.4.4 Change Manager for Employee events without

rectification

For employee events that do not have rectifications, the process is the same as the one described in
the employee events section, except for the fact that when the system identifies that the event was
changed and requires a rectification, the rectification is not generated by the Change Manager and a
warning message is displayed.

This rule is processed for events with classification R (Employee events without rectification).

4.4.5 Change Manager for Periodic events

Periodic Events work similarly to employee events, because they can be rectified, and they can also be
deleted through the generation of event S-3000. The periodic events can be generated and sent to
eSocial national environment in case the payroll period10 is not closed11 or in case was already
reopened12. The Change Manager identifies that a payroll period was already closed and generates
automatically the reopen (S-1298) event.

10
Payroll period here refers to the eSocial concept, using the eSocial events S-1299 and S-1298. That
is, this concept does not relate to payroll period defined in the system.
11
The closing of the payroll period is done when you send the event S-1299 (closing of periodic events).
12
The reopening of the payroll period is done when you send the event S-1298 (reopening of periodic
events), and this event can only be send for a period when you have already sent the event S-1299.
This rule is used for events with the classification P (Payroll events Periodic events).

The business class generates an event for the payroll period, and the Change Manager evaluates one-
by-one to decide which event must be executed.

Find below examples of the Change Manager behavior using the payroll cluster as reference.

Situation System reaction/Comments/Response

You calculate a regular monthly payroll
for May for an employee without any
recalculation, and you run for the very
first time the data extraction for the
event type S-1200 in productive mode.
You send the event to the eSocial and
have it accepted in the system.
You send the event S-1299 to close the
May payroll period for eSocial.
You calculated a regular payroll for the
same employee for June recalculating
the May payroll. Then you ran the data
extraction for the event type S-1200 in
productive mode for June.
The business class generates just one event for the period
of the payroll (May), and the Change Manager sets the
event as insertion.
This step is done by other eSocial components.
The rules for the Change Manager behavior for this event
is in the section 4.4.6.
The business class generates two events: one for May
(with the original and the recalculated payroll) and another
one for June. The Change Manager identifies that the May
payroll period was already closed, and then automatically
generates the event S-1298 (reopening of periodic events).

4.4.6 Change Manager for Periodic events on employer level

The Change Manager manages events S-1298 (reopening of periodic events) and S-1299 (closing of
periodic events) for Periodic Events on employer level.

These events do cannot be rectified. In this case, a warning message is displayed.

You cannot delete these events after you have sent them to eSocial. In case a Periodic Event on
Employer level was not already sent to eSocial, the Change Manager deletes this event from the
database.

This rule is used for events with the following classification:

E (Periodic event on employer level)
Q (Periodic event on employer level without rectification)

4.5 Appendix E When a new version of the class is

necessary

For future maintenance, it is necessary to create a new version of the processing class and delimit the
V_T7BREFD_EVTYPE (or V_T7BREFD_EVT_C) table view in following situations:
You have removed fields/structures/tables from the event structure
You have changed the hierarchy of the event structure
You have changed the structure of event
 You have changed the information type of the event
You have changed the selection class that the processing class is expecting, for example from
CL_HRPAYBR_EFDF_EE_SELECTION to CL_HRPAYBR_EFDF_SELECTION

4.6 Appendix F HCM Objects

For a faster approach on developing events that have employee information, SAP recommends the use
of the HCM Objects framework.

The HCM Objects framework has been developed to retrieve employee master data (infotype data)
more easily. This framework also reads customizing data that are related to the infotypes.

In case the HCM Objects framework does not have the information that you need for eSocial, SAP
recommends that you consider whether the information necessary is applicable to be inserted in the
framework. If so, enhance the HCM Objects framework; otherwise implement it on your processing
class.

Insert the following information in the HCM Objects framework:

New infotypes
Retrieval of information related to infotype entries
Reading of customizing tables which depend on an infotype entry, like absence mapping

Do not insert the following information in the HCM Objects framework:

Conversion of data to report format

Example of code
DATA lo_employee TYPE REF TO cl_hrpadbr_employee.
DATA lo_org_assign TYPE REF TO cl_hrpadbr_org_assign.
DATA ls_t001p TYPE REF TO t001p.

* Create the employee instance

CREATE OBJECT lo_employee
EXPORTING
Iv_pernr = lv_pernr.

* The the infotype 0001 Casting the object returned

lo_org_assign ?= lo_employee->get_last( iv_infty = 0001
iv_begda = lv_begda
iv_endda = lv_endda ).

* Read the entry of T001P which have information about the subarea
ls_t001p = lo_org_assign->get_hr_subarea( ).

ls_output_data-bukrs = lo_org_assign->ms_org_assign-bukrs.
ls_output_data-moabw = ls_t001p-moabw.


4.7 Appendix G Data Dictionary Structures

Event Data Structure Name

S-1040 HRPADBR_EFDE_S_ROLES
S-1060 HRPADBR_EFDE_S_WRK_ENV
S-1070 HRPADBR_EFDE_S_ADMIN_LAWSUIT
S-1080 HRPADBR_EFDE_S_PORT_OPERATOR
S-1250 HRPADBR_EFDE_S_RURAL_ACQUIS
S-1260 HRPADBR_EFDE_S_RURAL_MKT
S-1270 HRPADBR_EFDE_S_NONDOCK_WORKR
S-2210 HRPADBR_EFDE_S_CAT
S-2220 HRPADBR_EFDE_S_ASO
S-2240 HRPADBR_EFDE_S_WORKPLACE_ENV
S-2241 HRPADBR_EFDE_S_NOXIOUS_ENV

4.8 Appendix H XML Generation Classes

Event XML Generation Class

S-1040 CL_HRPAYBR_EFDX_ROLES
S-1060 CL_HRPAYBR_EFDX_WORK_ENV
S-1070 CL_HRPAYBR_EFDX_ADMIN_LAWSUIT
S-1080 CL_HRPAYBR_EFDX_PORT_OPERATOR
S-1250 CL_HRPAYBR_EFDX_RURAL_ACQUIS
S-1260 CL_HRPAYBR_EFDX_RURAL_MKT
S-1270 CL_HRPAYBR_EFDX_NDOCKWRK
S-2210 CL_HRPAYBR_EFDX_CAT
S-2220 CL_HRPAYBR_EFDX_ASO
S-2240 CL_HRPAYBR_EFDX_WORKPLACE_ENV
S-2241 CL_HRPAYBR_EFDX_NOXIOUS_ENV