Understanding Events
This topic provides overviews of initial data loading, ongoing transaction reporting, driver and cross-reference tables, splitting of events, mapping process, stage table loading, processing options, and ways to identify events for eSocial reporting.
After the completion of eSocial setup (which includes the activation of eSocial functionality, the activation, setup, and sequencing of initial events, the activation of participating companies, as well as legal code mappings), the next step is to load PeopleSoft’s initial data.
Initial data refers to foundational data that is stored in setup tables. It includes information about companies, establishments, job codes, shifts, taxable locations, service takers, employees and non-employees, all of which is vital in supporting various labor and payroll transactions.
The initial loading of events is launched through run control pages. These events must be submitted for all participating companies before the implementation of eSocial. Going forward, initial loading events need to be submitted, for example, when you activate a company (newly created or acquired), add new establishments to a new company, or when a company starts using a new setID for basic tables, which is defined on the SetID Group Page.
There are two initial load processes that need to be run, in this sequence:
Load basic table data
Load employee data
Initial Basic Table Data Loading
By default, the process includes the launching of these events:
S-1000 - Employer Data
S-1005 - Establishment and Building Site Table
S-1010 - Wage Types Table
S-1020 - Tax Location Table
Inactive initial events are not included in the eSocial Basic Tables Initial process.
Run this data loading process on the eSocial Basic Initial Page.
Initial Employee Data Loading
After the initial load process for basic table data is completed successfully, the next step is to send information about employees, which, based on the run control setup, can include active employees with temporary absence, employees who are fulfilling prior notice, as well as inactive employees who have recently been terminated but are expecting payments from the employer. Any individual who was hired on or after the company becomes active for eSocial reporting, as well as on or before the eSocial on PeopleSoft date specified for the company, his or her most current effective-dated employee data (in reference to the company’s eSocial on PeopleSoft date) will be reported to eSocial. Data for individuals who were hired after the eSocial on PeopleSoft date will be reported to eSocial using the S-2200 or S-2300 event.
Important! As delivered, future rows for employees and non-employees are not considered during the initial employee data loading process. To support future rows, customers have to create their own triggers and launch them during S-2200 or S-2300 processing.
By default, the process includes the launching of these events:
S-2200 - Employees Initial Loading and Hiring
S-2300 - Workers who have no employment relationship – Begin
Data changes for employees with employment relationship after the initial data load will be reported to eSocial through S-2200 event rectifications, S-2205, or S-2206 events, depending on when the changes were made. For example, an employee (hire date: January 10th) was reported to eSocial through the S-2200 event. If a new effective-dated row is added today (May 1st) for this employee in the Job Data component, this contract data change will be reported to eSocial using the S-2206 event. If a new effective-dated row is also added today in the Personal Data component for the employee’s marital status change, this personal data change will be reported using the S-2205 event. However, if any of these changes is made in the row effective-dated January 10th, an S-2200 event (with the Rectification indicator turned on) will be created to report to eSocial that the hiring data has been modified.
Similarly, data changes for workers with no employment relationship will be reported through S-2300 event rectifications and the S-2306 event.
Important! As delivered, existing rows with a future date are not considered during the initial employee data loading process. To support these rows, customers have to create their own triggers for S-2205, S-2206, or S-2306 to report the changes.
Run this data loading process on the eSocial Employee Initial Page.
After the initial data for participating companies is loaded and then transmitted to the eSocial environment successfully, eSocial is live. From now on, certain updates about companies and their employees in HCM need to be reported to the Brazilian federal government through eSocial. The government identifies a list of events that companies need to capture and report to the eSocial system when they occur. These events collect information about companies, employees, as well as transactions that are performed regarding payments to individuals, payroll and labor obligations, social security and other fiscal impacts, and must be submitted within the time-frame permitted by law. Depending on the nature of the events, some need to be reported to eSocial almost as soon as they occur, while others can be processed periodically in a batch.
Events are grouped into these high-level categories:
Basic table events.
Non-periodic events.
Periodic events.
Totaling events.
Termination events.
Events are interdependent of one another, and there is a sequence in which they are launched by category, and within their own category. The sequence of events for each category is established in the Events Sequence by Category BRA component.
Important! eSocial accepts only one single register for any given data entry for the same period (month and year) and company (represented by its sole headquarter establishment). In PeopleSoft, data rows are controlled by effective date (day, month and year). When a basic table code (for example, job code) has more than one row with the same month and year in their effective dates (for example, September 1st, 2016 and September 21st, 2016), the row with the most current effective date in the period will be reported to eSocial for that period if needed. Every time a new effective-dated row is entered in one of the basic tables in PeopleSoft, the system checks if the corresponding event for the same month and year period has already been sent. If so, instead of triggering a new event for the new effective-dated row, a change event is invoked to update the data on the eSocial environment.
Basic Table Events
Basic table events build the foundation of data that companies need to set up and maintain in the eSocial system. These events record basic table data (such as job codes and work shifts) and employer information (such as identification of employers, its establishments and construction work sites). They are included in the initial data loading process.
After eSocial goes live, changes made to basic table and employer data on HCM component transactions must be sent to eSocial environment no later than the 7th day of the month following the updates, or prior to the transmission of any event that requires the changed information for validation, whichever comes first.
To ensure the proper handling of periodic and non-periodic events from employers and payroll calculations going forward, it is important that the data that is loaded to the eSocial system be accurate at all times.
Refer to Global Payroll for Brazil eSocial Event Layouts for a list of system-delivered basic table events.
Non-Periodic Events
Non-periodic events, or labor events, are legal labor facts that can happen on any business day between an employer and its employees through HCM component transactions. Examples of non-periodic events include hiring, salary changes, accidents at work, absences and so on. These facts impact the granting of rights, as well as the fulfillment of labor, social security and tax obligations.
Refer to Global Payroll for Brazil eSocial Event Layouts for a list of system-delivered non-periodic events.
As these events occur and are confirmed, they need to be transmitted to the eSocial system shortly. For example:
Information related to hiring employees or contract workers without employment relationship has to be submitted by the end of the day immediately, prior to the commencement of service.
Information related to accidents at work has to be submitted on the next work day following the occurrence of the accident. In case of death, it needs to be reported immediately.
Information related to the rest of the labor events must be sent either by the seventh day of the following month after the change becomes effective, or before the submission of any periodic event (for example, payroll) that uses the updated labor information for validation, whichever comes first.
Note: If the termination payment date by when an event needs to be submitted is a bank holiday, the work day immediately preceding this bank holiday becomes the new submission due date.
Periodic Events
Periodic events are legal labor facts that occur on a predefined schedule. Examples of periodic events include payments related to payroll, calculation of social security contributions and income taxes. Companies need to report earnings and deductions paid to their employees and non-employees through payroll, according to the predefined wage types codes. These codes indicate whether or not payments are taxable, or have impacts on averages for vacations, 13th salary and terminations, among others. They must also report compensation amounts regarding payroll exemption on each establishment to compose the INSS (Social Security Tax) calculation basis.
Since periodic events typically occur as batch processes in the background, they are captured for eSocial reporting through run control pages.
In general, periodic events need to be reported to eSocial by the 7th day of the month following their occurrences. Companies can generate tax payment forms to collect payments only after these events are submitted.
Note: If the date by when an event needs to be submitted is a bank holiday, the work day immediately preceding this bank holiday becomes the new submission due date.
Refer to Global Payroll for Brazil eSocial Event Layouts for a list of system-delivered periodic events.
Totaling Events
Totaling events provide summaries of compensation-related calculations to companies after the submission of their employees’ compensation data to the Brazilian government. They are returned from the eSocial environment of the government, after events (such as S-1200, S-1210, S-1299, and S-2299) are received and processed successfully.
Refer to Global Payroll for Brazil eSocial Event Layouts for a list of system-delivered totaling events for eSocial, and how they are run to retrieve the information requested.
Termination Events
Termination events are a subset of non-periodic events. They are used to report information related to terminations, which can happen on any business day between employers and employees (or non-employees).
In general, termination-related information has to be submitted on the next work day following the termination date, if the termination is planned (for example, tendering of a work notice, or end of a fixed term contract).
In all other cases, termination information needs to be sent to the eSocial system no later than 10 calendar days following the termination date.
Note: If the termination payment date by when an event needs to be submitted is a bank holiday, the work day immediately preceding this bank holiday becomes the new submission due date.
Refer to Global Payroll for Brazil eSocial Event Layouts for a list of system-delivered termination events.
The driver and cross reference tables record and control all events to be submitted to the eSocial environment. Every XML file generated for an eSocial event is based on a record from the driver table, and the cross-reference table for the record’s event. These two records contain the same two keys (driver sequence and driver split sequence) that uniquely identify a transaction in PeopleSoft.
The set of driver tables consist of:
The driver table
The driver table stores general information about the identified event, such as driver sequence, action, status, timestamps, different IDs (Protocol, Batch, Receipt and Event) and so on.
Cross reference tables
A cross reference table is present for each supported event layout. Cross reference tables store key information about the data being added, changed or deleted on components. Each table has at least the same key structure as its base HCM table.
Driver and cross-reference tables contain only references to retrieve all the information needed to generate XML files for eSocial events that occurred. Their records can be added, updated, or deleted as a result of:
Online transactions - when a transaction is saved in an eSocial-mapped component, a subscription message is fired, containing the transaction information needed for eSocial reporting. Records are added to the driver and corresponding cross-reference tables based on the component and subscription message content.
Batch processing, which are:
Initial data loading, which inserts driver and cross-reference records.
Mapping process and staging table loading, which update record statuses.
XML file generation, which update record statuses.
Status update from web service
PeopleSoft receives status updates regarding file submissions from eSocial environment through a web service. Status information is updated in driver records as a result.
The driver table is the key element in driving the eSocial process flow; it is also the basic table that is used for the monitoring tool.
In PeopleSoft HCM, certain data is organized in ways that are different from how the eSocial environment collects information, which is by company. Subsequently, when an update of such data occurs and it triggers an insertion of a row in the driver and cross-reference tables, the system needs to do the same for all companies that use the updated information. The splitting of the row (creating new ones) ensures that the correct number of entries are loaded to staging tables, which are later used to generate XML files for all impacted companies.
The splitting of events applies to these types of data:
Information that is keyed by setID, such as basic table data.
See the Understanding SetID and Company Mapping topic for more information.
Employee data that is keyed by employee ID.
An example of it is employee’s personal data. An employee may have jobs with different companies and while job data is keyed by employee record number (which corresponds to a company), personal data isn’t. When the employee updates his or her personal information, the updated information needs to be sent to all companies where he or she has a contract.
Payroll elements, which can be used by multiple companies.
Note: Splitting of events is handled as part of the initial data loading and online transaction processes.
As an important part of the eSocial functionality, the mapping process:
Gathers the one-to-one field values that are required by eSocial event reporting, based on the input provided in the driver and cross-reference tables.
Extracts all the information required for the events to be reported, and populates it to corresponding staging records.
After the mapping process is finalized, a call can be made to the XML generation AE process to create XML outputs for event data found in staging tables.
Updates driver rows with corresponding statuses based on the options selected on the run control page and data being processed.
The mapping process is triggered when the Prepare Data option is selected on run control pages that process eSocial events. For more information, see Processing Phases and Options.
Staging tables are a set of database tables that are designed based on the event layouts published by the government. They are used to store the event information that the system uses to generate XML files.
Here are the high-level steps to load processed event data to staging tables for XML file generation, which is part of the mapping process:
Identify rows from the driver record that match run control parameters, and insert them to the Temporary record.
Clean up staging records. Check and remove any existing, irrelevant data rows (from previous processes) from the staging records, which are also available in the Temporary record.
Insert data from PeopleSoft application records and the Temporary record to corresponding staging records.
The eSocial functionality can access data a lot quicker from staging tables than from the original PeopleSoft transaction tables, posing as little impact as possible on performance.
Update the row statuses:
For rows that are added to staging tables successfully, row status is set to MAPP in Temporary and driver records.
For rows that cannot be added to staging tables, row status is set to ERRM in Temporary and driver records.
For rows that have XMLs created successfully, row status is set to XCRT in Temporary and driver records.
Generate log file entries for data rows that are not added to staging records successfully.
Global Payroll for Brazil creates eSocial events for reporting using application engine (AE) processes that are launched from run control pages. Built for initial data loading and specific event categories, these run control pages support a list of processing phases and options:
Prepare Data
The Prepare Data option looks for new, modified, and deleted information, and creates driver data for it. The mapping process takes all the driver records (which are in the RDY status and do not have XML files generated for them yet) that meet the criteria listed on the run control page, and loads the processed data to staging tables. For rows that are loaded to staging tables successfully, their driver record status is updated to MAPP; for those that are not loaded successfully, their driver record status is changed to ERRM instead.
Note: In the case of initial data loading, the processes first identify the information from PeopleSoft HCM-based records that meet the criteria listed on the run control pages and include references in driver and cross-reference tables, before processing the information and loading it to staging tables.
After verifying the results, users may perform this step again if changes occur, or if issues are fixed and they need to be reflected in the data.
For example, after performing the Prepare Data step, a user adds new job codes to the company. As each new job code is added, the system creates a new driver record. When the user performs this step again, the process identifies these new driver records and includes them.
The Prepare Data step can be run multiple times, initially for the entire selection of events (or transactions) and companies on the run control page, and subsequently for those with changes or fixes.
This option is selected and becomes unavailable for edits if the Reprocess option is selected. It becomes unavailable for edits if the Delete option is selected.
Reprocess
Use this option to process again all pending entries (in the RDY status) that meet the criteria listed on the run control page. Users may use it occasionally, for example, when a change of parameter or data impacts all the events but a new driver record is not created to reflect the change.
Note: The Reprocess option works differently for initial loading processes. When the Reprocess option is selected for loading initial basic table or employee data, the mapping process takes driver rows that are generated for initial data loading (GPBR_ORIG_ESOC equal to I), and are in the RDY, MAPP, ERRM, or XERR (error occurred in the XML generation) status, but do not have XML files generated for them yet.
This option becomes unavailable for edits if the Delete option is selected.
Create XML
If users are satisfied with the mapping process result, they can select this option to generate the XML outputs for driver data rows (in the MAPP row status) that are inserted to staging tables. When selected, the status of all driver records that meet the criteria listed on the run control page is updated to SUCC. A call is then made to invoke the XML generation application engine (AE) program (GPBR_GEN_XML) to create XML outputs for those matching data rows. After the AE process is completed, the status for each processed driver record is updated to XCRT.
This option becomes unavailable for edits if the Delete option is selected.
See Also Creating XML Outputs for Events
Skip Data in Error
This option is available for selection if the Create XML option is selected. When Skip Data in Error is selected, the Create XML process ignores records that are in the "error" status, and continues with the creation of XML files for those that are clean. It gives users the option to generate XML files for error-free records and send files to eSocial first if they choose to do so, and work on the skipped records later.
Note: (For S-1299 events) If both Create XML and Skip Data in Error options are selected for a company on the eSocial Period Controls Page, and the company happens to have calendar groups that aren’t finalized or events that aren’t submitted successfully for the specified period, no XML file will be created for that company and the selected event.
If Skip Data in Error is not selected but Create XML is, the process stops if error is found in any data record included in the Create XML process.
This option becomes unavailable for edits if the Delete option is selected.
Delete
This option deletes the initial load data rows that were inserted in the driver, cross reference, and staging tables through the Prepare Data or Reprocess option.
This option is available if none of the other options are selected. When the Delete option is selected, all other options are no longer editable.
Customers choose this option if they discover that wrong setIDs were linked to companies on the SetID Group page by mistake.
Identify Calendars
As the first step for generating payroll events, this option selects all calendars that match the selection criteria on the run control page. Calendar information is used in the mapping process for payroll events. In order to be used in payroll event processing for companies, calendars must be:
Finalized.
Associated with run types that are configured on the Run Types Page for the payroll events (S-1200 and S-1210).
Within the competency period specified on the run control page.
For S-1200 events, employers submit detailed payroll wage types by employee and accrual month. A calendar is included if the begin date and end date of the period ID match the specified competency period.
For S-1210 events, employers submit net payments by employee or non-employee and payment date. A calendar is included if the payment date falls within the specified competency period.
When companies handle cash basis, vacation, termination, advance and any other off-cycle payments, it is normal that the actual payment date does not fall within the period to which the payment pertains. Therefore, it is possible to see calendars being processed in two periods, one by competency and the other by payment date. In an example where both the period ID and payment date of a payroll entry fall within the specified competency period, the system generates both S-1200 and S-1210 events; if the period ID falls outside and the payment date within the competency period, only the S-1210 event is generated.
The Identify Calendars option is specific to S-1200 and S-1210 events. When either event is selected, the system automatically selects the other event, the Identify Calendars option, as well as the Validate Elements option. The Identify Calendars option can be processed with Validate Elements option alone, or together with other options (such as Prepare Data or Reprocess).
If the Reprocess option is selected for S-1200 and S-1210 events, the system selects the Prepare Data option automatically.
Validate Elements
This option validates if all accumulator elements (either Total Earnings or Total Deductions) that are entered on the Run Types Page are also set up on the Wage Types Table Page. Information is logged, if accumulator elements on the Run Types page cannot be found on the Wage Types Table page, or if the Wage Types Table page contains more elements than the accumulators that are defined on the Run Types page.
The Validate Elements option is specific to S-1200 and S-1210 events. The system automatically selects this option when both events are selected on the eSocial Payroll Events page.Validate Calendar and Events
This option validates, for the competency period and companies selected on the eSocial Period Controls Page, if all associated calendar groups are in the 70 (Finalized) or 75 (Finalized with Bank) calculation status and that all events have been submitted successfully before the request to close the period can be processed. If there are calendar groups that are not finalized or events that are still awaiting receipt numbers from the government, an S-1299 event cannot be created. A PDF report with information about pending calendar groups and events is generated for company administrators to review and take actions accordingly.
The system automatically selects this option if the Prepare Data, Reprocess or Create XML option is selected on the eSocial Period Control page.
Cancel Data
This option deletes the existing mapping (driver and staging tables) for matching data rows that do not already have generated XML outputs. After the cancelation process is completed, the status of impacted rows is changed to RDY.
The Cancel Data option does not apply to S-1200, S-1210, S-1280, S-1298, S-1299, S-2299, and S-2399 events.
Skip Closing Rule
When this option is selected, the system generates the S-1299 event with an extra tag (<naoValid>), instructing the Government to skip the validation of the REGRA_VALIDA_FECHAMENTO_FOPAG rule when processing the event. Bypassing this validation reduces the processing time of the event, especially when the company has many employees and movements during the competency period.
The Skip Closing Rule option is specific to S-1299. It becomes editable if the selected event is S-1299 and the Prepare Data option is selected on the eSocial Period Controls Page.
Typically, the lifecycle of an eSocial event begins when a user saves a transaction online in an eSocial-mapped component, such as Job Data, Job Code, Company, Establishment, and so on. The save action creates a trigger in the system that determines if the saved transaction is subject to eSocial reporting and if so, with which event code to report it.
After that, the mapping process comes in to prepare data for the event. This process extracts all the information that is required to create the event, and populates tags (fields) accordingly. It also makes sure that future rows are not processed if their effective dates do not fall within the period currently assessed by eSocial.
Once the mapping process is completed, the event is ready for another process where an XML output for the event gets generated. Lastly, the XML output is submitted to a third-party program and then the government of Brazil through web services.
This table lists the eSocial events, their event types (basic table and non-periodic), and the HCM component pages from which data is retrieved to generate corresponding events (when transactions are saved):
|
Event Layout - Report Name |
Event Type |
Components to Collect Event Data |
|---|---|---|
|
S-1000 - Employer Data |
Basic Table |
|
|
S-1005 - Establishment and Building Site Table |
Basic Table |
|
|
S-1010 - Wage Types Table |
Basic Table |
|
|
S-1020 - Tax Location Table |
Basic Table |
|
|
S-1030 - Job Code Table |
Basic Table |
Important! This eSocial report is no longer required and therefore has been inactivated in the S-1.0 version. Job Code Table (JOB_CODE_TBL)
|
|
S-1050 - Work Shift and Time Labor Table |
Basic Table |
Important! This eSocial report is no longer required and therefore has been inactivated in the S-1.0 version.
|
|
S-1060 - Workplace Table |
Basic Table |
Important! This eSocial report is no longer required and therefore has been inactivated in the S-1.0 version. Workplace Table BRA (WORKPLACE_BRA)
|
|
S-1070 - Administrative and Legal Proceedings |
Basic Table |
Administrative/Legal Proceedings BRA (LEGAL_PROC_BRA)
|
|
S-2200 - Employees Initial Loading and Hiring |
Non-periodic |
|
|
S-2205 - Personal Data Changes |
Non-periodic |
|
|
S-2206 - Employment Contract Changes |
Non-periodic |
|
|
S-2210 - Accident at Work Communication (CAT) |
Non-periodic |
|
|
S-2220 - Occupational Health Monitoring |
Non-periodic |
|
|
S-2230 - Temporary Absence |
Non-periodic |
|
|
S-2240 - Environmental Working Conditions |
Non-periodic |
|
|
S-2250 - Termination Previous Notification |
Non-periodic |
Important! This eSocial report is no longer required and therefore has been inactivated in the S-1.0 version.
|
|
S-2298 - Employee Reinstatement |
Non-periodic |
|
|
S-2299 - Termination |
Termination |
|
|
S-2300 - Workers who have no employment relationship – Begin |
Non-periodic |
|
|
S-2306 - Workers who have no employment relationship - Changes |
Non-periodic |
|
|
S-2399 - Workers who have no employment relationship - End |
Termination |
|
|
S-2500 - Labor Proceedings |
Non-periodic |
Assign Labor Proceedings BRA (GPBR_LABOR_PROCEED)
|
|
S-2501 - Labor Proceeding Tax |
Non-periodic |
Labor Proceeding Tax BRA (GPBR_LABOR_PRC_TAX)
|
|
S-3000 - Event Exclusion |
Non-periodic |
|
|
S-3500 - Exclusion Event - Labor Proceeding |
Non-periodic |
|
Companies are required to report hiring transactions to eSocial one day before new hires start working. In some situations, companies may not be able to collect all the information needed to submit employees initial loading and hiring events (S-2200) in time. As an alternative, they can submit pre-hiring events (S-2190)—a simplified version of hiring events that requires little information for reporting.
Companies run the GPBR_ES_P_HIRE application engine (AE) process for pre-hiring events. It takes the information from the run control page, inserts data rows to driver and cross-reference tables, calls the mapping process that cleans up data and populates staging tables, and calls the XML file generation process that creates XML files for eSocial submission all in one continuous process. Unlike the AE processes for other events, GPBR_ES_P_HIRE does not provide options to prepare data, reprocess, or create XML files separately.
If, after the submission of a pre-hiring event, the hiring of a worker cannot be completed, the company must inform eSocial by sending an exclusion event (S-3000) for the pre-hiring event no later than the end of the worker’s estimated hire date.
Before an S-2200 event is generated, the system checks if a pre-hiring event already exists for the same employee ID. If such event exists, the system validates the data (if pre-hiring event is submitted successfully), submits the S-2200 event and updates the status of its pre-hiring record accordingly.
See eSocial Pre-Hiring Event Page and eSocial Pre-Hiring Monitor Page