SAP NetWeaver

How-To Guide

How To Create a New Event for e-

Social

Applicable Releases:
SAP_HR 6.00 and higher

Version 2.1
January 2018
© 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 SAP’s 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.
2.1 CEVR: Customizable eSocial Validation Rules and new reports.

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 ..............................................................................................8
2.2.9 Reports.........................................................................................................9
2.2.10 CEVR: Customizable eSocial Validation Rules............................................ 10
3. How to Create a New Event for eSocial ........................................................................ 12
3.1 Create the processing class of the event ................................................................. 12
3.2 Customize the eSocial information type table .......................................................... 12
3.3 Define the eSocial application tables ....................................................................... 12
3.4 Create a data structure ........................................................................................... 13
3.5 Implement the processing class .............................................................................. 14
3.6 Customize the events deadline table rules .............................................................. 15
3.7 Customize the eSocial event type table ................................................................... 16
3.8 Customize the eSocial table for Change Manager ................................................... 17
3.9 Create the classes for CEVR rules (optional)........................................................... 18
3.10 Customize the CEVR framework (optional) ............................................................. 18
4. Appendix........................................................................................................................ 20
4.1 Appendix A – Objects reference .............................................................................. 20
4.2 Appendix B – Example of processing class implementation ..................................... 20
4.3 Appendix C – Example of logging errors.................................................................. 24
4.4 Appendix D – Change Manager .............................................................................. 24
4.4.1 Change Manager for Table Events.............................................................. 25
4.4.2 Change Manager for Employee Events ....................................................... 26
4.4.3 Change Manager for Deletion Events.......................................................... 27
4.4.4 Change Manager for Employee events without rectification ......................... 27
4.4.5 Change Manager for Periodic events .......................................................... 27
4.4.6 Change Manager for Periodic events on employer level .............................. 28
4.5 Appendix E – When a new version of the class is necessary ................................... 28
4.6 Appendix F – HCM Objects ..................................................................................... 29
4.7 Appendix G – Data Dictionary Structures ................................................................ 30
4.8 Appendix H – XML Generation Classes .................................................................. 30
4.9 Appendix I – Example of validation class of CEVR framework ................................. 31

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 eSocial’s 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.

 R

HR User

R
External Services
R R R R

SAP_HR
R

Master Data Maintenance eSocial

Event Generation Event Visualization External Cookpit Integration Events Monitor Scheduler Pulling
Maintain HR Master Data
R R R R

R R R R

Dispatcher
HR Renewal

R
BAdi Implementation Communication
Data Engine
Employee Self-Service R
R

R R
Change Manager
R
R
R R
XML Generation

Data Management CEVR

Event Data Extraction Logic
Log Data

Transmission
Event Customizing
eSocial Event Data
R

Employee Data

Master Data Time Management Customizing Payroll

Netweaver

R
SOA Manager Government Entity

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.
 · CEVR (Customizable eSocial Validation Rules): Framework to define rules to be executed in
the generation of an event or in the sending process.

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

¡ IF_HRPAYBR_EFDF_VALID_RULE: interface to implement the rules of the “CEVR:

Customizable eSocial Validation Rules” framework.

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

1
It means that no field in the table has value. It is checked with the ABAP statement “IS INITIAL”.
 · 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

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

2
We consider as dummy table, a table which contain only the mandatory fields of the eSocial
application table
 · For verification: Initial status, defined when
[Event needs verification] [Event does not need verification] the event is created. It is created automatically.

For verification Ready to send · 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
· Processing into batch: Set when the event
was selected to be sent and assigned to a
batch.
Wai ting response

· Sent: Set when the event is sent to the

[Event regeneration] component that will fire the WebService. It is
fired by the user.
Waiting correction Accepted

· Accepted: Set when the event was received

and it is correct. Status changed automatically
when the Government answer is received.
Manually cancelled Obsolete

· 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-2900 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-2900.

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-2200, S-2205, S-2300, 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-1210.

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

eSocial: Monitor de lotes (RPU_PAYBR_EFD_BATCH_MONITOR program): it is the report which will

display the batches and allow the user to control its statuses.

eSocial: Envio de eventos (RPU_PAYBR_EFD_SCHEDULER program): this report is used to send the
events to the eSocial environment. This report select the events and trigger jobs to create the batches
and send them to the authorities.

eSocial: Consulta de lotes (RPU_PAYBR_EFD_POOLING_SCHED program): this report is used to check

the processing and status of a batch which was already sent to the eSocial environment. This report
select the batches and trigger jobs to check the batches responses.

eSocial - Reprocessamento de resposta de lotes (RPU_PAYBR_EFD_BAT_REPROC_RESP program):

this report is used to reprocess batch which errors occurred during the processing of batch response by
the system. It just select batches with specific statuses and reprocess them.

eSocial: Exclusão de eventos/lotes (RPU_PAYBR_EFD_EVT_DELETION program): this report can be

used to delete events and batches from the system. This report is a tool designed only for test purpose,
and it cannot be executed in production system. This report does not evaluate the rules defined by the
eSocial to the delete the events and batches.

2.2.10 CEVR: Customizable eSocial Validation Rules

The “Customizable eSocial Vacation Rule” is a framework which allows you to define validation rules
that check for specific conditions while the system is generating or sending an eSocial event.

The CEVR has the following components:

· Rules: you customize a rule for a specific event. In the rule you define the system behavior in
case the rule validation fails.
· Conditions: for each rule you need to define one or more conditions. Each condition has an
ABAP class linked which contains the code to run the validation. The framework run condition
 by condition until the first condition returns success. It means, the framework interprets the
conditions as an IF with OR.
· Parameters: For each condition, you must defined the parameters needed by the ABAP class.
The system allows you define as parameter any field of the event header (T7BREFD_EVENT
table), event data or a fixed value.

For example, in case you want to create a rule which checks if the event S-2200 (Cadastramento Inicial
do Vínculo e Admissão/Ingresso de Trabalhador) or S-2300 (Trabalhador Sem Vínculo de
Emprego/Estatutário - Início) was sent before the event S-1200 (Remuneração de trabalhador vinculado
ao Regime Geral de Previd. Social), you need:
· Create a rule to the event S-1200;
· Create a condition which gets the information from S-1200 and checks if the event S-2200 was
already accepted;
· Create a condition which gets the information from S-1200 and checks if the event S-2300 was
already accepted;
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
9. Create the classes for CEVR rules (optional)
10. Customize the CEVR framework (optional)

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:

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 Begin date (BEGDA): represents the begin date of the event.
o End date (ENDDA): represents the end date of the event.
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

3.9 Create the classes for CEVR rules (optional)

In case there are rules which make sense to implement using the CEVR framework, then you need to
create a class for each type of validation you want to do. Following are the steps explaining how to
create a single class:

· In transaction SE24, create the class to process the validation and the class must implements
interface IF_HRPAYBR_EFDF_VALID_RULE. Create the class as a public class. Note that the
naming convention for SAP is CL_HRPAYBR_EFDR_<free_name>, and that there is no naming
convention for customer classes.

· The class must implement the two interface methods:

o Method GET_PARAM_DEFINITIONS
§ Return a table defining which parameters the validation rules require.
§ All the parameters defined will be filled by the customizing and must have the
following source:
· Event data
· Fixed values (input directly in the customizing)
§ The table has three fields:
· FIELD_NAME: Name of the parameter which will be identified in the
method VALIDATE.
· DTEL_NAME: Name of the data element of the parameter.
· MULT_OCURR: In case the parameter has multiples occurrence inside
the event.

o Method VALIDATE
§ Return a Boolean value indicating if the validation result is ok or not.
§ It receives as parameter an instance of the class
CL_HRPAYBR_EFDF_PARAMETERS, which was instantiated by the eSocial
framework and it contains the parameters values according to the definition you
have done in the method GET_PARAM_DEFINITIONS.

3.10Customize the CEVR framework (optional)

To create the rules in CEVR, you use a set of three views:

· Regras para eventos (V_T7BREFD_RULE)
· Condições de regras para eventos (V_T7BREFD_RULED)
 · Parâmetros das condições de regras para eventos (V_T7BREFD_RULEP)

In the V_T7BREFD_RULE view, you create specific rules for an event type, including the possible
outcomes in case a rule fails:
· A warning message is generated on the log/event.
· An error message is generated on the log/event during the generation of an event (during the
sending process, the error message aborts the sending of the event).
· An abort that generates an error message on the log/event and aborts the current process
(during the generation or sending of an event).

In the V_T7BREFD_RULED view, you create several rule conditions to be executed for every rule
configured in the V_T7BREFD_RULE, including the specific order of these conditions. This order is
important because, if one of the conditions is valid, the system will stop processing the next conditions
(it works like a conditional OR). In this view, you also configure an ABAP class that uses the
IF_HRPAYBR_EFDF_VALID_RULE interface.

In the V_T7BREFD_RULEP view, you customize the parameters that are used for every condition
configured in the V_T7BREFD_RULED view. The parameters that you define must have one of the
following values:
· A text defined in the customizing entry (for that, you select fixed value field)
· The value of a field of the event header (fields from the T7BREFD_EVENT table)
· The value of a field (or a table of values) from the event information
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
CL_HRPAYBR_EFDR_EVENT_EXISTS
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
Class used by the CEVR

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 in charge of deals with the rectification, deletion and
change of events. In order to use the Change Manager functionality properly, the Business Extractor
Class must generate the events using just the data that are currently valid. It means, the Business
classes must not control rectification, deletion and change of events.

For example:
· You create an absence infotype for an employee.
· When you run the framework selecting the employee and the absence period, the business
class must generate an event related to the absence infotype
· If you delete the infotype and run again the business class, the event related to the absence
infotype must not be generated, then the framework will be able to identify that the event related
to that absence was deleted.

The Change Manager identifies if an event had a change on its data in order to generate the rectification.
It means that after the business class generate an event, the Change Manager evaluates the content of
the event (data) to check if the event was already send to the Government, and basically do the
following:
· Send the event as insertion if it was not send yet
· Send the event as change/rectification if the event was already send and the data is different
 · Discard the event generated by the business class if the event was already send and the data
is equals
· Generate a deletion event

The Change Manager works different for table events and worker events.

4.4.1 Change Manager for Table Events

Table events do not have rectification; they just have changes and deletions.

This rule is used for events with the following classifications:

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

The business class should generate an event for each table entry and delimitation, and the Change
Manager will evaluate one-by-one to decide what have to 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 events generated
above, you run again the data
extraction for an event type in
productive mode
After sending and accepting all the
event above, you change an entry in a
table 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 the 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 must generate all the events
considering the table entries. The Change Manager will
discard all the events which were generated and the
content is equals to the one which were already send. The
event that has a change in the content will be saved in the
database with change operation.
The processing is similar to the one described above, but
the Change Manager will identify that you have already
send to the Government an event and this event was not
generated right now by the business class. Then, the
Change Manager generates automatically an event with
deletion operation, in order to deletes from the eSocial
server the event that you have sent before. The deletion
event (which was generated by the Change Manager) and
the event which was previous sent to the eSocial are
automatically linked, it means that you can easily identify
that you have sent and event to the eSocial and now you
will delete it. After the deletion event is send and accepted
by the eSocial, the original event is set to ‘obsolete’ status.

5
The database here is the table of the event which are manage by the Data Manager component of the
framework
6
To identify the table event in the database, it is considered the following fields 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

The employee events have rectification which is basically the resending of an event, but the exclusion
of its event is done via the event S-3000, it means, that when you need 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 equals to ‘W’ (Employee events – Non-periodic events).

The whole processing of the Change Manager for Worker Events is similar to the processing for Table
Events, except for:

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

· For rectification:
o The Change Manager searches in the database for an event 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:
§ Event type
§ Information type
§ Information value
§ Begin date from the selection screen
§ End date from the selection screen
o It is necessary in order to identify correctly the event in the database for the situation
where the employee had an infotype that had the dates changed.
o The rectification of an event is a new event that is generated and linked to the original
one.

Bellow are an example of the change manager behavior using some infotype as reference which
generates the event S-2205 (change to employee registration data).

Situation System reaction/Comments/Response

You have created an infotype entry and the
generation report for the event S-2205.
You sent the event to eSocial and have it
accepted in the system.
You have changed the infotype entry 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 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 events.
When the rectification event is accepted, the original
event is set to ‘obsolete’ status.

8
By deletion here, it is understood an event which exists in the database for the selection period but it
was not generated in this execution by the Business Class.
9
The event S-2900 cannot be generated by the user using the standard generator 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. It became useful to easily identify which events
should be regenerated for each employee.

The table which stores the infotype log is T7BREFD_EVTOGEN. This table is maintained by the framework
and it 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 table T7BREFD_ITEVTRIG, as explained in the steps to create and
event.

4.4.3 Change Manager for Deletion Events

The deletion event (S-3000) cannot be deleted and rectified, it means that this type of events only
generates insertions. In fact, this rule is applied to the events with the classification equals to D (Delete
events).

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

4.4.4 Change Manager for Employee events without

rectification

For employee events which does not have rectifications, the process is equals to the one described for
in the Change Manager for Employee Events section, except to the fact that when the system identifies
that the event was changed and would requires a rectification, the rectification is not generated by the
Change Manager and a warning message is displayed to the user.

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

4.4.5 Change Manager for Periodic events

Periodic events work similar to the employee events, because they have rectifications and the deletions
are done by the event S-3000. The periodic events in case the payroll period 10 is not closed11 or it was

10
Payroll period here refers to the eSocial concept, using the eSocial event S-1299 and S-1298. It is
not related 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).
already reopened12. The change manger is able to identify that a payroll period was already closed and
generates automatically the reopen (S-1298) event.

This rule is used for events with the classification equals to P (Payroll events – Periodic events).

The business class should generate an event for payroll period, and the Change Manager will evaluate
one-by-one to decide what have to be executed.

Bellow are an example of the change manager behavior using the payroll cluster as reference.

Situation System reaction/Comments/Response

You calculate a regular 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 run 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 just set the
event as insertion.
This step done by other eSocial components.
The rules of the behavior of the change manager 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

Periodic events on employer level is the change manager in charge of manage the events S-1298
(reopening of periodic events) and S-1299 (closing of periodic events).

These events do not have rectifications, then, in this case, a warning message is displayed to the end
user.

You cannot delete these events after you have sent it to eSocial. In case the event 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

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 send the event S-1299.
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
4.9 Appendix I – Example of validation class of CEVR
framework

Method GET_PARAM_DEFINITIONS
METHOD if_hrpaybr_efdf_valid_rule~get_param_definitions.

DATA ls_param_def TYPE hrpadbr_efdf_s_param_def.

ls_param_def-field_name = 'EVENT TYPE'.

ls_param_def-dtel_name = 'HRPADBR_EFD_EVENT_TYPE'.
ls_param_def-mult_ocurr = abap_false.

APPEND ls_param_def TO et_t_param_def.

CLEAR ls_param_def.

ls_param_def-field_name = 'BEGDA'.
ls_param_def-dtel_name = 'BEGDA'.
ls_param_def-mult_ocurr = abap_false.

APPEND ls_param_def TO et_t_param_def.

CLEAR ls_param_def.

ls_param_def-field_name = 'ENDDA'.
ls_param_def-dtel_name = 'ENDDA'.
ls_param_def-mult_ocurr = abap_false.

APPEND ls_param_def TO et_t_param_def.

ENDMETHOD.

Method VALIDATE
METHOD if_hrpaybr_efdf_valid_rule~validate.

DATA lo_t7brefd_event TYPE REF TO cl_hrpaybr_t7brefd_event.

DATA lo_extractor TYPE REF TO if_hrpaybr_efdf_data_extractor.
DATA lo_factory TYPE REF TO cl_hrpaybr_efdf_factory.
DATA lx_exception TYPE REF TO cx_hrpaybr_exception.
DATA lt_exist_events TYPE hrpadbr_t_t7brefd_event.

* Information needed for the validation of this class

DATA lv_begda TYPE begda.
DATA lv_endda TYPE endda.
DATA lv_event_type TYPE hrpadbr_efd_event_type.
DATA lv_status TYPE hrpadbr_efd_status.
DATA lv_inf_value TYPE hrpadbr_efd_inf_value.
DATA lv_inf_type TYPE hrpadbr_efd_inf_type.

io_parameters->get_parameter(
EXPORTING
iv_name = 'EVENT TYPE'
IMPORTING
ev_value = lv_event_type ).

io_parameters->get_parameter(
 EXPORTING
iv_name = 'BEGDA'
IMPORTING
ev_value = lv_begda ).

io_parameters->get_parameter(
EXPORTING
iv_name = 'ENDDA'
IMPORTING
ev_value = lv_endda ).

lo_factory = cl_hrpaybr_efdf_factory=>get_instance( ).

lo_extractor = lo_factory->get_extractor_instance(
iv_event_type = lv_event_type
iv_date = lv_endda ).

lv_inf_type = lo_extractor->get_information_type( ).

lo_t7brefd_event = cl_hrpaybr_t7brefd_event=>get_instance( ).

lo_t7brefd_event->read_with_equal_status(
EXPORTING
iv_event_type = lv_event_type
iv_begda = lv_begda
iv_endda = lv_endda
iv_inf_type = lv_inf_type
iv_inf_value = lv_inf_value
iv_status = lv_status
IMPORTING
et_t7brefd_event = lt_exist_events ).

IF lt_exist_events IS NOT INITIAL.

rv_result = abap_true.
ELSE.
rv_result = abap_false.
ENDIF.

ENDMETHOD.