Global Payroll for Brazil eSocial Event Layouts

General Rules for Basic Table Events

Here are several general rules that apply to all basic table events, after the initial data loading for them are completed and eSocial becomes effective:

• In order for events to be generated and submitted properly for companies implementing eSocial:

  • Companies must be enabled and configured using the Company Parameters component (event rules, setID setup, and XML option setup).

  • The effective dates (or begin dates) of basic table changes (including insertion, change, or deletion of data) must either be equal to or greater than the eSocial on PeopleSoft date of companies on the Company Parameters Page. For example:

    Effective date: used by S-1000 and S-1005 events

    Begin date: used by the S-1010 event

    Both dates: used by the S-1020 event

• The eSocial system (of the Brazilian government) accepts only one report from any Basic Table event code at any given period (month and year) for any eSocial-enabled company, whereas in PeopleSoft, effective dates for data rows are captured in the form of day, month, and year. When there are more than one effective-dated row for an event code during the same month and year period, the latest one is submitted to eSocial. Each time a new effective-dated row is added in PeopleSoft, the system checks to see if an event has already been sent for the same month and year period. If yes, a change event, in which the new row information is entered in the alteracao group tag of the XML file, is generated to send the update to the eSocial system. If no, an inclusion event, in which the new row information is entered in the inclusao group tag, is generated instead.

• In this example, suppose that three effective-dated job code rows are entered in PeopleSoft:

  1. KRSI1 setID, 120000 job code, Administrator, effective date: September 01, 2016, active effective status

  2. KRSI1 setID, 120000 job code, Director, effective date: September 03, 2016, active effective status

  3. KRSI1 setID, 120000 job code, President, effective date: September 20, 2016, active effective status

  • If these rows are processed all at the same time (for example, initial data loading), one Job Code event gets generated for the latest data row (#3), and the row information is populated in the inclusion section of the generated XML file.

  • If these rows are entered and processed at different times after eSocial becomes effective, three different Job Code events get generated as a result. The row information of the first event is populated in the inclusion section of the generated XML file. The second event contains row information of #2 in the change section of its XML file, and the third event with row information of #3 in the change section as well.

• Here is another example for effective-date changes. Suppose that three effective-dated job code rows are entered in PeopleSoft, and the effective date of one row is changed:

  1. KRSI1 setID, 120000 job code, Director, effective date: September 01, 2016, active effective status

  2. KRSI1 setID, 120000 job code, President, effective date: September 20, 2016, active effective status

  3. KRSI1 setID, 120000 job code, Senior President, effective date: changed from October 04, 2016 to September 25, 2016, active effective status

  • If the old effective date of the changed row is the only date of its month and year period, and the new effective date is the latest date of its month and year period (like the example), two different Job Code events get generated as a result. The old effective date is populated in the exclusion (the exclusao XML file tag) section of the first generated event. In the second event, the information of the new effective date (Senior President for effective date September 2016) is populated in the change section of its XML file.

  • If the old effective date of the changed row is the only date of its month and year period, for example:

    KRSI1 setID, 120000 job code, Director, effective date: September 01, 2016, active effective status

    KRSI1 setID, 120000 job code, President, effective date: September 20, 2016, active effective status

    KRSI1 setID, 120000 job code, Senior President, effective date: changed from October 04, 2016 to November 01, 2016, active effective status

    One Job Code event gets generated. In this Job Code event, the old and new effective dates are populated in the change section of its XML file.

  • If the old effective date is not the only one and is the latest date of its month and year period, and the new effective date is one but not the latest of its month and year period, for example:

    KRSI1 setID, 120000 job code, Director, effective date: September 01, 2016, active effective status

    KRSI1 setID, 120000 job code, President, effective date: changed from September 20, 2016 to October 1, 2016, active effective status

    KRSI1 setID, 120000 job code, Senior President, effective date: October 04, 2016, active effective status

    One Job Code event gets generated. In this Job Code event, the new row information (Director) for September 2016 is populated in the change section of its XML file. The existing information for October 2016 stays intact because the changed row is not the latest data row.

  • If the old and new effective dates are not the latest or the only date of their month and year period, no events are generated.

• This example shows a few effective-dated row deletion scenarios.

  • If a row is deleted, and it is the only row in its month and year period, for example:

    KRSI1 setID, 120000 job code, Director, effective date: September 03, 2016, active effective status

    KRSI1 setID, 120000 job code, President, effective date: September 20, 2016, active effective status

    KRSI1 setID, 120000 job code, Senior President, effective date: October 04, 2016, active effective status (deleted)

    One Job Code event gets generated. In this Job Code event, the deleted row information is populated in the exclusion (the exclusao XML file tag) section of its XML file.

  • If a row is deleted, and it is the latest of the rows in its month and year period, for example:

    KRSI1 setID, 120000 job code, Director, effective date: September 03, 2016, active effective status

    KRSI1 setID, 120000 job code, President, effective date: September 20, 2016, active effective status (deleted)

    KRSI1 setID, 120000 job code, Senior President, effective date: October 04, 2016, active effective status

    One Job Code event gets generated. In this Job Code event, the deleted row information is populated in the change section of its XML file.

  • If a row is deleted, and it is not the latest or the only date of its month and year period, no event is generated.

• This example shows a few effective-dated row insertion scenarios.

  • If a row is added, and it is the latest of the rows in its month and year period, for example:

    KRSI1 setID, 120000 job code, Director, effective date: September 20, 2016, active effective status

    KRSI1 setID, 120000 job code, Senior President, effective date: October 04, 2016, active effective status

    KRSI1 setID, 120000 job code, Vice President, effective date: October 20, 2016, active effective status (added)

    One Job Code event gets generated. In this Job Code event, the added row information is populated in the change section of its XML file.

  • If a row is added, and it is the only row in its month and year period, for example:

    KRSI1 setID, 120000 job code, Director, effective date: September 20, 2016, active effective status

    KRSI1 setID, 120000 job code, Senior President, effective date: October 04, 2016, active effective status

    KRSI1 setID, 120000 job code, Vice President, effective date: November 01, 2016, active effective status (added)

    One Job Code event gets generated. In this Job Code event, the added row information is populated in the inclusion section of its XML file.

  • If a row is added, and it is not the latest or the only date of its month and year period, no event is generated.

• When a change is made to a basic table (for example, job code) and the change does not apply to the effective date, PeopleSoft generates an event (with update in the change section) only if the change happens to the data row with the latest date of its month and year period.

Scenarios

This example describes a few scenarios for submitting wage types table information and exemption proceeding details to the eSocial system:

• If an element row is added to a wage types table, for example:

  1 wage types table ID; 2501 wage type code, PREMIO element, INSS: 92, IRRF: 11, FGTS: 11, begin date: September 1, 2016

  Because this element is associated with a code that requires exemption proceeding details to be entered, the proceeding information is specified for a particular company using that element, for example:

  1 wage types table ID, KRC company, 3265659789 proceeding number, CP (INSS) proceeding ID, PREMIO element, begin date: September 1, 2016

  One wage types table event gets generated for the element row, and the row information is populated in the inclusion section (the inclusao group tag) of the generated XML file.

• If a company (KRI) is newly linked to the wage types table mentioned above on the Company Details BRA page, and it needs to specify exemption proceeding details for an element (PREMIO) that already has proceeding code identified, for example:

  1 wage types table ID; 2501 wage type code, PREMIO element, INSS: 92, IRRF: 11, FGTS: 11, begin date: November 1, 2016

  1 wage types table ID, KRI company, 2822587222 proceeding number, CP (INSS) proceeding ID, PREMIO element, begin date: November 1, 2016

  One wage types table event gets generated for the element row, and the row information is populated in the inclusion section of the generated XML file. Note that a new begin date is selected for the element to avoid error when generating the event.

• If data is updated in an element row that has been submitted to eSocial, for example, the DSR option is selected on an element row, one wage types table event gets generated for each company that is linked to that element and begin date. The updated information is populated in the change section (the alteracao group tag) of the XML file.

• If the begin date of an existing element row is updated along with other changes that require exemption proceeding details to be entered, for example:

  1 wage types table ID; 1205 wage type code, ADIC NOTURNO element, INSS: changed from 11 to 92, IRRF: changed from 11 to 92, FGTS: 11, begin date: changed from September 1, 2016 to January 1, 2017

  1 wage types table ID, KRC company, 2566225322 proceeding number, CP (INSS) proceeding ID, ADIC NOTURNO element, begin date: January 1, 2017

  1 wage types table ID, KRC company, 1452252229 proceeding number, IRRF proceeding ID, ADIC NOTURNO element, begin date: January 1, 2017

  One wage types table event gets generated for the element row, and the row information is populated in the inclusion section of the generated XML file if the new begin date is the only date of its month and year period. If proceeding details are missing, error message is generated in the event monitor.

• If the begin date of an existing element row is updated along with a change that requires exemption proceeding details to be entered, for example:

  1 wage types table ID; 1205 wage type code, ADIC NOTURNO element, INSS: changed from 11 to 92, IRRF: 11, FGTS: 11, begin date: changed from September 1, 2016 to January 1, 2017

  Multiple companies use the same wage type code and element, but only one company has specified exemption proceeding details, for example:

  1 wage types table ID, KRC company, 2566225322 proceeding number, CP (INSS) proceeding ID, ADIC NOTURNO element, begin date: January 1, 2017

  One wage types table event gets generated for the element row, and the row information is populated in the inclusion section of the generated XML file for the KRC company. Error messages are generated in the event monitor for other companies that didn't specify proceeding details for the updated element.

• If the begin date of an existing element row is updated along with other changes that no longer require additional proceeding details to be entered:

  1 wage types table ID; 1205 wage type code, ADIC NOTURNO element, INSS: changed from 92 to 11, IRRF: changed from 92 to 11, FGTS: 11, begin date: changed from January 1, 2017 to February 1, 2017

  One wage types table event gets generated for the element row, and the row information is populated in the inclusion section of the generated XML file if the new begin date is the only date of its month and year period. No action is necessary for the element's proceeding details with the old begin date (January 1, 2017).

• If proceeding details for a few elements are deleted, one wage types table event gets generated for each element for the associated company. In each event, the deleted row information is populated in the exclusion section (the exclusao group tag) of the XML file.

Initial Loading

The S-1060 event is a basic table event that is also included in the initial load process for basic tables (GPBR_ESOC_ILB) as default. When the initial load process runs for the S-1060 event and a company, the system generates an S-1060 event for each establishment (service taker, or third-party establishment) that is associated with the current row of the workplace definition of that company. If the effective date of the workplace definition is earlier than (<) the Health/Safety Go Live date (for example, January 1, 2019), the go-live date is used as the <iniValid> date of the event.

After the initial loading of workplaces is completed, the eSocial system reports any new, deleted, or changes to workplaces to the Government using the S-1060 event.

Online Transactions After Initial Loading

Here are several examples that describe the behaviors of the S-1060 event when workplaces are created, updated, or deleted from the PeopleSoft system after initial loading process is completed:

• If a new row is added to a workplace definition, and its effective date (for example, December 15, 2018) is greater than the date (for example, December 1, 2018) of the current row that was sent to the Government, making it the new current row for the same month-year period, the system generates an S-1060 event (change event) for each associated entity (establishment, service taker, or third-party establishment), in which the information from the new current row (with the December 15, 2018 date) is entered in the alteracao group tag of the event’s XML file. The <iniValue> tag value (2019-01) in these events remain the same.

  If a new row is added to a workplace definition, and this time the effective date is earlier than the date of the current row that is submitted to the Government, no event update is expected.

  If a new row is added to a workplace definition after the go-live date, and it is the only row in the month-year period (for example, February 2019) of its effective date, the system generates an S-1060 event (inclusion event) for each associated entity, in which the information of this new row is entered in the inclusao group tag of the XML file.

• If the effective date of the current row is changed from December 1, 2018 to February 1, 2019 (a date that belongs to a different month-year period), and this row becomes the only row in the new month-year period, the system generates an S-1060 event (inclusion event) for each associated entity with the information of this new row in the inclusao group tag, and generates an S-1060 event (change event) for each associated entity with information from the row that is now current for the December 2018 month-year period in the alteracao group tag). Suppose that the effective date of the current row is changed to a different month-year period but it does not become the most current row in the new period, no new S-1060 event is generated.

  If the effective date of the current row is changed (from February 1, 2019 to January 1, 2019), and as a result of the update, it becomes the most current row in the new month-year period (January 2019), and the old month-year period (February 2019) no longer has rows. In this case, the system generates an S-1060 event (exclusion event) for each associated entity, in which the information from the February 2019 row is specified in the exclusao group tag, and generates an S-1060 event (change event) for each associated entity with the information of this new current row (January 2019) in the alteracao tag.

  If the effective date of the current row is changed (from May 1, 2019 to June 1, 2019), and the row becomes the only row in the new month-year period (June 2019). In this case, the system generates an S-1060 event (change event) for each associated entity by specifying the updated effective date in the <novaValidade> tag, as the new value (June 2019) is the only row in the period and does not already exist in the Government’s environment.

• If the workplace information (for example, description) is changed in the current row, the system generates an S-1060 event (change event) for each associated entity with the updated information.

  If the information is changed but is not in the most current row of the month-year period, no event update is expected.

• If a new entity (establishment or service taker) is added to the current row (newly added or existing) of the workplace information after an initial load, the system generates an S-1060 event (inclusion event) for the newly added entity. If an associated entity is removed from the row, the system generates an S-1060 event (exclusion) for it.

  Clicking the All Establishments (or All Service Takers) button on the Workplace Table BRA page updates the corresponding grid with all active establishments (or service takers) for the associated company. If new establishments are added and some removed because they are no longer active, the system generates an S-1060 event:

  • (Inclusion event) For each newly added entity.

  • (Exclusion event) For each deleted entity.

  • (Change event) For each entity that is still associated with the company workplace.

• If the current row is deleted from the workplace definition, the system generates an S-1060 event (change event) for each associated entity with information from the row that is now current for the same month-year period.

  If the current row is deleted and it was the only row in the month-year period, the system generates an S-1060 event (exclusion event) for each associated entity.

  If a row is deleted but it is not the current row of the month-year period, no event update is expected.

General Rules

Here are several rules that apply to the Administrative and Legal Proceedings event:

• Only active administrative and legal proceedings will be considered.

• Complementary data will only be mapped for the Judicial type of proceedings that are created for Tax only or Tax and FGTS and used in the creation of XML files.

• Tax suspension information will only be mapped for proceedings that are created for Tax only or Tax and FGTS and used in the creation of XML files.

Setup Tasks

Because Global Payroll for Brazil delivers support for the S-1070 event after the initial eSocial implementation in PeopleSoft, for customers who like to implement S-1070 event processing in PeopleSoft, they need to follow these steps to prepare their environments:

1. Enable the Administrative and Legal Proceedings functionality on the Adm/Legal Proceedings Parameters BRA Page.

   This is a prerequisite for S-1070 event processing.

2. Enter proceeding information on the Administrative/Legal Proceedings BRA Page.

3. Select the Import Historical Data option on the Events Setup Page for the S-1070 event. The event must be inactive for the option to display.

   Warning! Perform this step only if you have been using a different system to process S-1070 events, and would like to switch it over to Global Payroll for Brazil (where the rest of your eSocial events are being processed).

4. Add Government-accepted proceeding data (data that was previously processed in a different system) to text files to be loaded into the PeopleSoft system. Then load the historical data on the Import Historical Data BRA Page. Refer to the same topic for the expected format of the text file for data import.

   Warning! Perform this step only if you have been using a different system to process S-1070 events, and would like to switch it over to Global Payroll for Brazil (where the rest of your eSocial events are being processed).

5. Activate the S-1070 event on theEvents Setup Page and Events Activation Page.

6. Perform initial loading for the S-1070 event on the eSocial Basic Initial Page.

   Warning! Perform this step only if you are implementing eSocial in Global Payroll for Brazil as a new company, in which case the Initial Loading process will also need to be run for other Basic Table events.

   Before executing the Initial Loading process for the S-1070 event, be sure to evaluate the Government's implementation schedule for eSocial.

Start adding, updating, and deleting proceeding information in the PeopleSoft system. The eSocial Basic Tables process on the eSocial Basic Table Event Page handles the mapping and XML file creation for S-1070 event drivers that are generated for online transactions.

Scenarios

In these scenarios, assume that:

• Company eSocial on PeopleSoft date (“go-live” date): Jan 1, 2016.

• Driver for a proceeding record (effective date: Dec 1, 2015) has been added to PeopleSoft through the initial loading process and reported successfully to the Government. Driver date: Jan 1 2016 and driver status: GSUC.

Here are several examples that describe the behaviors of the S-1070 event when proceeding information is created, updated, or deleted from the PeopleSoft system as online transactions.

• If a new effective-dated row is added, and the effective date (Dec 10, 2015) is earlier than the go-live date but later than the existing row (Dec 1, 2015), the system generates an S-1070 event (change event) with information of the new row in the change section (the alteracao group tag) of its XML file for the 2016-01 period.

  If a new effective-dated row is added, and the effective date (Nov 1, 2015) is earlier than the date of the existing row, no event will be generated.

• If the effective date of the existing row is changed from Dec 1, 2015 to Mar 1, 2016, and the change makes this row the only row in the new date period (and the prior date period no longer has any row), the system generates an S-1070 event (change event) with the new date period (2016-03) in the novaValidade tag within the alteracao group tag for the 2016-01 period, because the new value does not exist in the Government environment yet.

  If the effective date of the existing row is changed and the new effective date (Dec 10, 2015) is earlier than the go-live date but later than the existing row (Dec 1, 2015), the result is similar to when you add a new effective-dated row—an S-1070 event (change event) is generated with the changed information in the alteracao group tag for the 2016-01 period.

• If the current effective-dated row (Dec 1, 2015) is deleted from the PeopleSoft system, and a row with an earlier date (Jan 1, 2014) still exists, the system generates an S-1070 event (change event) with information of the Jan 1 row in the alteracao group tag for the 2016-01 period.

  If the deleted effective-dated row is the one with the earlier date (Jan 1, 2014), no event will be generated.

• If a new effective-dated row is added, and its effective date is the latest (Jan 30, 2018) in the date period, the system generates an S-1070 event (change event) with information of the new row in the alteracao group tag for the 2018-01 period.

• If a new effective-date row is added (Jan 1, 2019) and it is the only row in that date period, the system generates an S-1070 event (inclusion event) with information of the new row in the inclusao group tag for the 2019-01 period.

• If the effective date of the existing row is changed from Jan 1, 2018 to Jan 1, 2019, and the change makes this row the older of the two rows in the new date period (and the prior date period no longer has any row), the system generates an S-1070 event (exclusion event) with information for the 2018-01 period.

• If the effective date of the existing row is changed from Jan 15, 2020 to Feb 1, 2020, and the change makes this row the only row in the new date period (and the prior date period has another row), the system generates an S-1070 event (change event) with information of the row in the prior date period for the 2020-01 period, and an S-1070 event (inclusion event) with information of the moved row for the 2020-02 period.

General Rules

Here are several general rules that apply to Compensation and Miscellaneous Payments event layouts:

• S-2200 and S-2300 events are preconditions for S-1200 - Compensation and S-1210 - Miscellaneous Payments events, as they collectively identify the payees (employees and non-employees) and their employment information needed for filing these two payroll events.

• A company needs to be associated with a wage types table on the (BRA) Company Details BRA Page in order for S-1200 and S-1210 events to be created for it. Information that is entered on the Run Types Page and Health Data Page of the Wage Types Table component is used in S-1200 and S-1210 event processing.

• S-1200 and S-1210 events are keyed by company, national ID CPF and eSocial reg number of the employee, and payroll period.

  As a general rule, only one S-1200 event and one S-1210 event are sent for the same company and employee for any given period. If the employee has more than one active employment relationship (more than one EMPL_RCD) with the same company, the payroll amounts of all jobs are summed and that total amount will be reported to the government.

  An exception to this rule is when S-1200 and S-1210 events need to be created for run types with different payroll types (annual or monthly). For example, it is common that employees receive the annual 13th month salary payment in addition to other monthly payments for the month of December. In this case, one S-1200 event will be created for the run type with the annual payroll type, and a second one will be created for the run type with the monthly payroll type. The same is true for S-1210 events.

  The relationships between run types, eSocial payroll events, and payroll types are established on the Run Types Page.

• If an employee has another job assignment within the same company recently, and the new job information is not yet included in the S-1200 (or S-1210) event that's created for the employee with his or her current job, the new job information and total payroll amount (for all of the employee’s jobs) will be added and updated in that S-1200 (or S-1210) event if the event has not yet been submitted, and rectified in the event if it has been sent to the government.

• Global Payroll for Brazil supports the S-1200 (or S-1210) event reporting of employees who have multiple employment relationships with different companies (companies that may or may not use Global Payroll for Brazil for payroll event reporting).

• Each S-1200 event and its associated S-1210 event are linked by payslip ID that is issued monthly for each payee. The payroll process assigns a number to each processed payment, and the payment amount declared in the S-1200 event must also have a corresponding net amount to be reported in an S-1210 event (linked to the S-1200 event with the same payslip ID) with the date on which the payment was made.

• If an individual was terminated with a rescission calculation during a competency period, the payroll information will be submitted to the government using either the S-2299 - Termination or S-2399 - Workers who have no employment relationship - End event layout instead of S-1200. The net payment will still be reported using an S-1210 event.

• If the company ID is updated in the job data of an individual after he or she is reported in the eSocial system, it is important that the finalized payroll of that competency period for the old company be reversed or canceled so that an exclusion of the S-1200 (or S-1210) event for the individual can be executed. A new calendar needs be calculated and finalized in the new company so that a new S-1200 (or S-1210) event can be reported to eSocial for the individual and the new company.

• If an action with payroll impact (for example, termination, hire, or bonus pay) occurs in a period for which an S-1200 (or S-1210) event has already been submitted to the government, the S-1200 (or S-1210) event is rectified or excluded as needed provided that the period is not closed (absence of a submitted S-1299 event), or is reopened (presence of a submitted S-1298 event).

  If the period is currently closed, and the S-1200 (or S-1210) event setup allows for processing after period closure, the S-1200 (or S-1210) event can still be rectified or excluded as necessary.

  If the period is currently closed, and the event setup does not allow for processing after period closure, the S-1200 (or S-1210) event will not be generated, and this result will be logged.

  If an action occurs in a period for which an S-1200 (or S-1210) event is not yet submitted to the government, corresponding driver data is updated accordingly and will be used for processing (or reprocessing) the S-1200 or (S-1210) event.

• Retroactive changes (such as outdated union labor conventions, change in absence type from sick to accident, or additional termination payments) pertaining to a closed period can be submitted by running S-1200 (or S-1210) events without the need to reopen the period. Such exceptions are permitted for these action reasons: SEFIP 650, SEFIP 660, and termination complementary information.

• When the payroll event AE process is triggered on eSocial Payroll Events page, it performs checks to make sure that the selected companies are active for eSocial reporting, the specified competency period is equal to or comes after the Adhere to eSocial date (month and year) and is not closed for periodic events, and the selected events are active. If any of these checks fails, the process stops and information is logged.

• The Identify Calendars option is the first processing option for S-1200 and S-1210 events. It is responsible for finding all the applicable calendars needed for creating selected events for the specified competency period and companies. All employees of selected companies and identified calendars who have compensation data within the specified competency period are included in the payroll event process run.

  A calendar needs to satisfy a few requirements to be considered in the payroll event creation process. See the Identify Calendars option description in the Processing Phases and Options section for more information.

  In a simple example where the calculation of a calendar is finalized, an S-1200 event is generated if the Period ID (representing the begin and end dates of the calendar month) is the same as the competency period. An S-1210 event is also created if the payee's payment date falls within the competency period.

  However, if the Period ID or the payment date is not the same as or does not fall within the competency period, for instance:

  • If Period ID or payment date of the payroll entry falls before the competency period, S-1200 or S-1210 is created with the Previous Competency status.

  • If Period ID or payment date of the payroll entry falls after the competency period, S-1200 or S-1210 is created with the Next Competency status.

• After the payroll event AE process is run, process results are available for review on the eSocial Processed Calendars - eSocial Payroll Events Page and eSocial Processed Employees - eSocial Payroll Events Page. These pages contain general information about the calendars that are identified for S-1200 and S-1210 events, and event statuses for each payee who was included in the process for the specified calendar ID and competency period.

  For payees who are associated with calendars that are not in the Finalized (70) or Finalized with Bank (75) calculation status, their S-1200 and S-1210 statuses are set to Awaiting Finalize Calendar. It means that preparation of payroll information for these payees is on hold until their calendar calculations are finalized.

  Note: For payees who have multiple employment relationships with the same company, it is important that all their payrolls have already been initiated before the Identify Calendars option is run. Their S-1200 and S-1210 statuses are set to Awaiting Finalize Calendar until all of their associated calendar calculations are finalized (70 or 75).

General Rules

Here are several rules for the Complementary Information to Periodic Events event:

• When the payroll event AE process is triggered on eSocial Payroll Events page, it performs checks to make sure that the selected companies are active for eSocial reporting, the specified competency period is equal to or comes after the Adhere to eSocial date (month and year) of selected companies and is not closed for periodic events, and the selected events are active. If any of these checks fails, the process stops and information is logged for further user actions.

• The payroll tax exemption setup for companies’ establishment headquarters on the Additional Info - Brazil Page determines if and how S-1280 events are created. Suppose that the payroll event AE process is invoked to create an S-1280 event for a selected company and competency period, the process looks up the company’s establishment headquarter row that pertains to the competency period, and:

  If the Other Sectors field value is set as Fully Replaced in its establishment headquarter, the system submits an S-1280 event. Here is an example of the data captured in this event:

  • The IndApuracao tag: 1 (monthly)

  • The perApur tag: Competency year and month

  • The indSubstPatr tag: 1 (fully replaced)

  • The percRedContrib tag: 0 (tax reduction percentage number)

  In addition to monthly S-1280 events, a company needs to report tax exemptions annually as well (for 13th month salary for instance). The system checks the payroll tax exemption record that is entered on the eSocial Payroll Tax Exempt BRA Page for the company and competency period. If the record exists and the period type is set to Annual, the system submits an S-1280 event for the annual type information on the competency month. Here is an example of the data captured in this event:

  • The IndApuracao tag: 2 (annually)

  • The perApur tag: Competency year

  • The indSubstPatr tag: 1 (fully replaced)

  • The percRedContrib tag: 0 (tax reduction percentage number)

  If the Other Sectors field value is set as Partially Replaced in its establishment headquarter, the system extracts the period type and tax reduction percentage information that is entered on the eSocial Payroll Tax Exempt BRA Page for the company and competency period, and populates it in the event. If the tax reduction percentage is not filled out for partially replaced company headquarters, the process for creating the S-1280 event cannot continue and a log will be generated as a result. Here is an example of the data captured in an S-1280 event for the Monthly period type:

  • The IndApuracao tag: 1 (monthly)

  • The perApur tag: Competency year and month

  • The indSubstPatr tag: 2 (partially replaced)

  • The percRedContrib tag: (tax reduction percentage number)

  Here is an example of the data capture in an S-1280 event for the Annual period type:

  • The IndApuracao tag: 2 (annually)

  • The perApur tag: Competency year

  • The indSubstPatr tag: 2 (partially replaced)

  • The percRedContrib tag: (tax reduction percentage number)

• If incorrect information is submitted to the government, rectifications of S-1280 events can be sent (for example, through deleting, changing or adding new tax exemption information, changing headquarters, or changing tax exemption rules in the headquarter) for periods when the changes occurred. The receipt number of the S-1280 event pending correction along with the data change will be included in the rectification event.

  • If the change is not on the period type or tax reduction percentage, nothing happens.

  • If the data has not been submitted to the government previously, it will be updated in the driver records and be reported in the next S-1280 event created for the same company and period. No rectification will be created.

• If the tax exemption information is deleted (for example, removal of header information or all information, or changing to a different period) from the eSocial Payroll Tax Exempt BRA page after the information was previously submitted to the government, an exclusion of the S-1280 event will need to be created.

  If an exclusion is created by mistake and has been reported to the government successfully, to undo the mistake you need to reenter the correct data on the page so that a new S-1280 event with that data can be submitted to the government again. If, however, the exclusion (created by mistake) has not yet been reported to the government, it will be replaced when the correct data gets updated in the driver records.

• Global Payroll for Brazil can undo exclusions and rectifications that are created by mistake, as long as if they are not yet submitted to the government.

General Rules

Here are several rules for the Closing Periodic Events event:

• When the S-1299 event is selected to run on the eSocial Period Controls Page for a specified period and list of companies, the system performs checks to make sure that the period is open or reopened, and that there are no pending events or non-finalized calendars for each selected eSocial-active company before an S-1299 event can be created. Events are considered pending if they have errors or do not have receipt numbers returned from the government.

  As the Validate Calendar and Events option is selected in the run control page for S-1299 event processing, and pending events or non-finalized calendars have been identified, the information is logged for further review and user actions (for example, skip or reprocess pending events, follow up with a payroll clerk to finalize calendars), and no S-1299 event is created. They need to be followed up on prior to submitting an S-1299 event again.

• If additional events (for example, corrections to data reported during open period, or new events pertaining to movement of the period) need to be submitted after the period is closed, exceptions can be made for events that have the Allowed after period closed option enabled in their setup.

  If the Allowed after period closed option is not enabled in the setup of an event layout, late events for it can still be considered for submission if a S-1298 event is sent to reopen the closed period.

  If the Allowed after period closed option is not enabled in the setup of an event layout of any event type, and no S-1298 event has been generated to reopen a closed period, any run control requests to process events of this layout after a closed period will be denied. These unprocessed, or blocked, events will be logged for eSocial personnel to follow up and take appropriate actions.

• If periodic events of different pay frequencies (monthly and annually) are reported for the same period, an S-1299 event will be submitted to the government for each frequency.

• A company is considered a company without movement if it doesn’t have any S-1200, S-1210, and S-1280 event processing for a competency period. To close a period for a company without movement, the S-1299 event (XML file) created has the No Movement flag turned on and the <compSemMovto> tag set to the month and year of the period that’s being closed.

  If the company continues to not have any S-1200, S-1210, and S-1280 event processing monthly in the years that follow, an S-1299 event needs to be submitted for each of these years in January (and can be skipped for the rest of the year). The No Movement flag is turned on and the value of the <compSemMovto> tag is set to the month and year of the last competency period when the company reported not having any movement.

  The system provides the Company Without Movement Page where you can review a list of S-1299 events that were submitted for companies without movement. The report is queried by company and it lists, for each data row, the period during which the company didn’t have any movement and the receipt number of the S-1299 event.

  A PDF report with information about pending events and calendar groups is generated for company administrators to review and take actions accordingly.

General Rules

Here are several rules for the Employer Union Contribution event:

• The S-1300 event can be processed together or independent of (before or after) the S-1200 and S-1210 events in a competency period as long as the period remains open.

• When the S-1300 event is selected to run on the eSocial Payroll Events page for a specified period and list of companies, the system performs checks on each selected company to make sure that the associated union contribution information has already been entered on the eSocial Employer Union Contrib Page before an S-1300 event can be created.

  For annual union contributions, select Compulsory as the contribution type. For monthly union contributions, select assistance, associative, or confederate as the contribution type.

• You can enter multiple rows of union contributions for any given company, period and period type that is specified on the eSocial Employer Union Contribution page.

  If the information is submitted for a compulsory, annual union contribution, the information (union code, contribution type, and amount) of all rows is included in a single S-1300 event for that company, competency year (month is not needed for annual type event), and annual period type.

  If the information is submitted for a voluntary, monthly union contribution, the information of all rows is also included in a single event for that company, competency period (year and month), and monthly period type.

  Note: A maximum of two S-1300 events can be submitted for a company in any given competency period if deemed necessary, one for the annual period type and one for the monthly period type.

• When new union contribution data is added for the first time, an S-1300 event is generated to submit the information to the government. But if the new data is added to a row with existing data that has been submitted previously, a rectification will be generated for the submitted S-1300 event with newly added data. Similarly, if a change (for example, amount change) or deletion (for example, removal of a row of union contribution) is made for data that is already sent to the government, a rectification will be sent to the government for the original S-1300 event. The rectification event contains the receipt number of the original event, and the current union contribution information after the change or deletion is made.

  If all rows of union contributions are deleted, an S-3000 - Exclusion event will be submitted to remove the deleted information from the government.

• If the period type of a submitted union contribution for a company is changed from Annual or Monthly, and a monthly union contribution for the same company and competency period is already submitted to the government, the system submits an S-3000 - Exclusion event to delete the annual type event, and a rectification event for the original S-1300 monthly event. The rectification event contains the receipt number and the current union information of the original event, plus the new information that was previously grouped as annual type contribution.

General Rules

Here are several rules for the Employees Initial Loading and Hiring event:

• It applies to employees with employment relationships (employees are associated with employee classifications that are specified on the Labor Regime Page, with a selected work type.

• It reports the employee data row with the most current effective date that is either earlier than or equal to (< or =) the eSocial on PeopleSoft date.

• For an employee to be included in the report, the employee’s hire date needs to be equal to or later than (= or >) the Company creation date, as well as equal to or earlier than (= or <) the eSocial implementation (eSocial on PeopleSoft) date.

  Information of individuals who are hired after the eSocial implementation date needs to be submitted using either this event (for employees) or the S-2300 - Workers who have no employment relationship - Begin event (for non-employees).

• The eSocial Reg. Number field value on the (BRA) Additional Information BRA Page is required for employees with employment relationships.

  Employees are not specific to or keyed by company, and can work for more than one company at a time. Therefore, any personal data change (personal data table are keyed by EMPLID) of an employee needs to be submitted to eSocial for all companies with which the employee has employment relationships.

  Job data is keyed by EMPLID and EMPL_RCD. With that, changes in job data need to be submitted to eSocial for the company associated with the employment record. If the employee has multiple employment relationships, the same number of S-2200 events need to be generated. In those events, the personal data section remains the same, the job data section, however, contains data that is distinct for each relationship.

• If an employee is in temporary absence, the <dtIniAfast> and <codMotAfast> tags of the S-2200 event are populated with the initial absence date and absence reason.

• If an employee was terminated before the implementation of eSocial, the <dtDeslig> tag of the event is populated with the termination date.

• If the only component or table that was updated for an employee is not effective-dated, and the maximum effective date for all components and records used to generate the event is earlier than or equal to (< or =) the eSocial implementation date, a rectification event is generated for the S-2200 event.

• An update in the CPF national ID, PIS, or birth date of an employee is considered a critical change. When it occurs, a rectification is generated for the S-2200 or S-2300 event as appropriate.

• If the update is made in the company or employee class in the employee’s job data, an S-3000 - Event Exclusion is generated for the corresponding event, followed by a new initial loading event for the employee.

• If an employee has personal data and job data rows that are effective-dated after the eSocial on PeopleSoft date, while the S-2200 event takes care of the current effective-dated row (the most current effective date that is earlier than or equal to eSocial on PeopleSoft date), future rows will be reported using the S-2205 - Personal Data Changes and S-2206 - Employee Contract Changes events respectively.

General Rules

These general rules apply to data change events, which include S-2205 - Personal Data Changes, S-2206 - Employment Contract Changes, and S-2306 - Workers Who Have No Employment Relationship - Changes:

• When a data change occurs in any component or page involved in the data change event, the system checks the type of employment relationship that the individual has with the company. It gets the employee class information of the individual from the job data, and finds out if he or she is an employee using the setup on the Labor Regime page (employee if a work type is selected).

  If the data change occurs in the Job Data component, the system also checks the setup of the Other Action/Reason page to identify which event layout to use.

  If the system is unable to identify all the information needed on these setup pages for the data change incident (for example, the individual’s employee class is not configured on the Labor Regime page, or the data change action is not set up on the Other Action/Reason page), no event is generated.

• When a data change occurs, the system checks if any event was already sent to eSocial with the same effective date <dtAlteracao>. If yes, it generates a rectification event for the sent event with the same change date instead of creating a new one.

  Note: The term change date refers to the effective date of the changed (add, update, or delete) data row. For information from tables that are not effective-dated, the change date refers to different dates. For example, if a change is made to the phone or email information on the Contact Information page of the Personal Data component, the change date refers to the current date.

• Employee data is not specific to any company (personal data tables are keyed by EMPLID, not EMPL_RCD). Therefore, when a data change of an individual needs to be reported to eSocial, that change, in the form of XML file, has to be submitted for all companies with which the individual has employment relationships. This is referred to as the splitting of events for multiple companies and is part of the mapping process.

  If the individual has multiple employment relationships with the same company, only one event is generated.

• If the change date falls within the closed period, the system sets the status of the event that is generated or rectified for the data change to Action Required. Events in this status requires user intervention; administrators can search for events by this status from the eSocial monitor and address them individually.

Personal Data Change Rules

Personal data changes for individuals can result in one or more events depending on a number of information, such as the change date, eSocial on PeopleSoft date, individual’s last hire date, and the setup on the Labor Regime page and Other Action/Reason page.

• Suppose that a date change for an individual needs to be submitted to eSocial, the system decides which events to create or rectify based on these general conditions:

  • If the change date is equal to or later than (= or >) the eSocial on PeopleSoft date, and later than (>) individual’s last hire date, the system generates a new event or rectifies the existing S-2205 - Personal Data Changes event.

  • If the change date is equal to or later than (= or >) the eSocial on PeopleSoft date, and earlier than or equal to (< or =) individual’s last hire date, the system rectifies the existing S-2200 - Employees Initial Loading and Hiring or S-2300 - Workers who have no employment relationship - Begin event, as well as the S-2205 event if needed.

  • If the change date and individual’s last hire date are both earlier than (<) the eSocial on PeopleSoft date, the system rectifies the existing S-2200 - Employees Initial Loading and Hiring or S-2300 event.

  • If the change date is earlier than (<) the eSocial on PeopleSoft date, and individual’s last hire date is later than or equal to (> or =) the eSocial on PeopleSoft date, the system rectifies the existing S-2200 or S-2300 event, as well as the S-2205 event if needed.

  Note: If the change date is earlier than (<) the eSocial on PeopleSoft date, an event is generated only if the change date is the most current one that is earlier than the eSocial on PeopleSoft date.

• If a rectification for an existing event, or a new event is generated, all events with the same event code and greater effective date than the rectified or generated event need to be rectified. For example:

  • (Update address) On August 15, address information of an employee was added and sent to eSocial. Event used: S-2200 - Employees Initial Load and Hiring. Effective date: September 1.

    On October 1, marital status was specified for the same employee and sent to eSocial. Event used: S-2205 - Personal Data Changes. Effective date or change date: October 1.

    On November 1, address information is updated for the same employee. Effective date: September 1.

    In this case of address update, the system sends rectifications to S-2200 and S-2205 (change date October 1) events.

  • (Add dependent) On August 15, address information of an employee was added and sent to eSocial. Event used: S-2200 - Employees Initial Load and Hiring. Effective date: September 1.

    On October 1, marital status was specified for the same employee and sent to eSocial. Event used: S-2205 - Personal Data Changes. Effective date or change date: October 1.

    On November 1, address information is added for the same employee and sent to eSocial. Event used: S-2205 - Personal Data Changes. Effective date or change date: November 1.

    On November 15, a dependent is added for the same employee. Effective date: September 1.

    In this case of adding a dependent, the system sends rectifications to S-2200 and S-2205 (change dates: October 1 and November 1) events.

  • When an event is being created, the system fills it with information with the current effective date from relevant table records. For example, if a new dependent (a wife) is added for an employee with October 1 as the effective date, the values (such as marital status, which would be updated together with the new dependent) that are used to fill out the corresponding event have the effective date equal to October 1 in their table records.

• If a data row is added, updated, or deleted, its effective date is not the most current one of the assessment period (month and year) and is earlier than (<) the eSocial on PeopleSoft date, no event is generated.

• If a data row is added, updated, or deleted, its effective date is the most current one of the assessment period, and is earlier than (<) the eSocial on PeopleSoft date, the system sends a rectification for the S-2200 or S-2300 event, as well as for the S-2205 event if needed. In this example, suppose that the eSocial on PeopleSoft date is September 1:

  On August 20, a name was added and sent to eSocial. Event used: S-2200 - Employees Initial Load and Hiring. Effective date: August 20.

  On August 20, a dependent was added and sent to eSocial. Event used: S-2200 - Employees Initial Load and Hiring. Effective date: August 20.

  On August 30, the dependent was deleted.

  In this case of row deletion, the system sends a rectification for the S-2200 event to remove the dependent information from eSocial.

• If a data row is deleted, its effective date is earlier than (<) the eSocial on PeopleSoft date and is earlier than or equal to (< or =) the individual’s last hire date, the last hire date is later than or equal to (> or =) eSocial on PeopleSoft date, the system sends a rectification event for the S-2200 or S-2300 event, as well as the S-2205 event if needed. Suppose that the eSocial on PeopleSoft date is September 1 and the individual’s last hire date is September 2:

  On August 30, a name was added and sent to eSocial. Event used: S-2200 - Employees Initial Loading and Hiring. Effective date: August 30.

  On August 30, a dependent was added and sent to eSocial. Event used: S-2200 - Employees Initial Loading and Hiring. Effective date: August 30.

  On September 2, the dependent was deleted.

  In this case of row deletion, the system sends a rectification event for the S-2200 event, as well as the S-2205 event if needed.

• Changes to employees’ CPF national ID, PIS, and birth date cannot be reported through data change events. To change this type of information, rectifications must be submitted for S-2200 events for employees, and S-2300 events for individuals without employment relationships.

  The system also sends rectifications to all S-2205 events that were sent prior to updates on IDs and birth dates.

  In addition, if the company or employee classification is changed in an employee’s job data, an S-3000 - Event Exclusion event needs to be generated for the corresponding event (S-2200, S-2298 or S-2300), followed by a new event.

Other Rules

• For data changes in table records that not effective-dated (for example, PERS_NID, PERSON_BRA, PERSONAL_PHONE, EMAIL _ADDRESS, PERSON, and PERSONAL_INFO_BRA), the system sends rectification events to corresponding events (S-2200, S-2300 and S-2205).

• Several data changes on the Personal Information BRA page (PERSONAL_INFO_BRA) impact S-1200 - Compensation events, not personal data change events. For example, NIF data, or the tax exemption date, is used when the system generates rectifications to S-1200 events.

  If a death certificate number is entered on the Personal Information BRA page, the system generates a rectification to the termination event for the individual.

General Rules

Refer to the General Rules section of the S-2205 - Personal Data Changes event.

Employment Contract Changes Rules

• If a rectification for an existing event or a new event is generated, all events with the same event code and greater effective date than the rectified or generated event need to be rectified as well. For example:

  (Update address) On September 10, an individual was hired and the job data information was sent to eSocial. Event used: S-2200 - Employees Initial Loading and Hiring. Effective date: September 10.

  On October 1, salary information was added for the employee and it was sent to eSocial. Event used: S-2206 - Employee Contract Changes. Effective date or change date: October 1.

  On October 10, the job code for the employee is updated for the same employee, and the information is sent to eSocial. Effective date: September 10.

  In this job data update example, the system sends rectifications to S-2200 and S-2206 (change date October 1) events.

• If a data row is added, updated, or deleted, no event is generated, if:

  • Its effective date is not the most current one of its month and year period, and

  • Its effective date is earlier than or equal to (< or =) the eSocial on PeopleSoft date, and

  • Its last hire date is earlier than (<) the eSocial on PeopleSoft date.

• If a data row is added, updated, or deleted, rectification events may be sent to S-2200, S-2300, S-2206, S-2306 as needed, if:

  • Its effective date is the most current one of its month and year period, and

  • Its effective date is earlier than (< ) the eSocial on PeopleSoft date.

  For example, on August 31 2016, an employee’s hire and salary information was loaded to eSocial. Event used: S-2200 - Employees Initial Load and Hiring. Effective date: July 01, 2015.

  On September 1 2016, more salary information was added for the employee and the information was sent to eSocial. Event used: S-2206 - Employee Contract Changes. Effective date or change date: October 1 2016.

  On September 5 2016, salary information is updated for the employee, and the information is sent to eSocial. Effective date: July 01 2015.

  In this salary update example, the system sends rectifications to S-2200 and S-2206 (change date October 1) events.

• This example shows an effective-dated row deletion scenario. Suppose that these rows exist in the PeopleSoft system:

  From the Job Data component:

  • KR00011 emplID, Hire action and Add reason, effective date: June 01, 2014

  • KR00011 emplID, Hire action and Add reason, effective date: July 01, 2014

  • KR00011 emplID, Pay action and Merit reason, effective date: July 01, 2015, event used: S-2200

  • KR00011 emplID, DTA action and DTA reason, effective date: September 01, 2016, event used: S-2206

  • KR00011 emplID, Pay action and Merit reason, effective date: September 01, 2016, event used: S-2206 (rectification), change date: September 01, 2016

  • KR00011 emplID, DTA action and DTA reason, effective date: November 01, 2016, event used: S-2206, change date: November 01, 2016

  • KR00011 emplID, DTA action and DTA reason, effective date: January 01, 2017, event used: S-2206, change date: January 01, 2017

  From the Payee Parameters page:

  • KR00011 emplID, begin date: June 01, 2014

  • KR00011 emplID, begin date: June 01, 2015, event used: S-2200

  • KR00011 emplID, begin date: September 01, 2016, event used: S-2206

  • KR00011 emplID, begin date: October 01, 2016, event used: S-2206, change date: October 1, 2016 (deleted)

  • KR00011 emplID, begin date: December 01, 2016, event used: S-2206, change date: December 1, 2016

  If a row is deleted, and:

  • Its effective date is equal to or greater than (= or >) the eSocial on PeopleSoft date (for example, September 1, 2016), and

  • Its effective date is greater than (>) the last hire date, and

  • The data row is the only one in its month and year period.

    The system generates an S-3000 - Event Exclusion event for the event with <dtAlteracao> that is equal to effective date of the deleted row. In this example, the exclusion event is generated for the S-2206 event with the effective date of October 1, 2016. In addition, rectifications are sent for events with <dtAlteracao> that are later than the excluded event. In this example, these events include the two S-2206 events with November 01, 2016 and January 01, 2017 effective dates from the Job Data component, and the S-2206 event with the December 1, 2016 effective date from the Payee Parameter page.

• This example shows an effective-dated row update scenario. Suppose that these rows exist in the PeopleSoft system:

  From the Job Data component:

  • KR00011 emplID, Hire action and Add reason, effective date: September 01, 2016, event used: S-2200

  • KR00011 emplID, DTA action and DTA reason, effective date: September 15, 2016, event used: S-2206, change date: September 15, 2016

  • KR00011 emplID, DTA action and DTA reason, effective date: changed from October 01, 2016 to November 1, 2016, event used: S-2206, change date: October 01, 2016

  • KR00011 emplID, Pay action and Merit reason, effective date: December 01, 2016, event used: S-2206, change date: December 01, 2016

  From the Payee Parameters page:

  • KR00011 emplID, begin date: September 01, 2016, event used: S-2206

  • KR00011 emplID, begin date: November 01, 2016, event used: S-2206

  • KR00011 emplID, begin date: January 01, 2017, event used: S-2206

  If the effective date of a row is updated, and:

  • Its (old) effective date is equal to or greater than (= or >) the eSocial on PeopleSoft date (for example, September 1, 2016), and

  • Its (old) effective date is greater than (>) the last hire date, and

  • The data row is the only one in its month and year period.

    The system generates an S-3000 - Event Exclusion event for the event with <dtAlteracao> that is equal to old effective date of the updated row. In this example, the exclusion event is generated for the S-2206 event with the effective date of October 1, 2016. A new event (S-2206) is generated for the new effective-dated row of November 1, 2016. In addition, rectifications are sent for events with <dtAlteracao> that are later than the exclusion event. In this example, these events include the two S-2206 events with November 01, 2016 and December 01, 2016 effective dates from the Job Data component, and the two S-2206 events with November 1, 2016 and January 01, 2017 effective dates from the Payee Parameter page.

• If multiple contract data actions are performed on the same day, and these changes trigger the same event, only one instance of this event is generated. For example, if you update a work shift code, change an employee’s risk level on the Payee Parameters page, and update a job code on the same day (October 1, 2016), and all of these changes need to be submitted to eSocial through the S-2206 event, the PeopleSoft system generates one S-2206 event with <dtAlteracao> set as October 1, 2016.

Employment Contract Changes Rules for Retroactive Payments

Sometimes, employees receive retroactive payments due to changes in contracts with their unions. These changes can be the result of collective agreements, collective disputes, collective conventions or legislative updates. The employer is responsible for reporting information of these salary increases to the Government, which then uses the data to calculate retroactive payroll using the S-1200 event accordingly.

Here is a list of rules that apply to the Employment Contract Changes event when reporting union-specific retroactive payments for employees (these rules are not applicable to non-employees):

• For S-2206 events to be generated for employees who receive retroactive payments due to union contract changes, they must be associated with unions on the Job Labor Page (the Union Code field).

  For unions with contractual changes, be sure to fill out the Union Contract Revision section of General Parameters Page. The system uses information provided here to determine the begin and end dates of the retroactive payroll, among other things.

  In addition, you also need to select the Collective Agreement Indicator option for a Data Change action and reason combination on the Other Action/Reason Page. The system uses this action and reason code for union-specific retroactive payroll processing. Oracle recommends that the same Data Change action for Sefip 650 be used for this purpose.

• When an employee job data row is added with the action and reason combination that is used for collective agreement, a positive compensation change percent on the Compensation Page, and an effective date that falls within the begin and end dates of the contract revision specified for the associated union of the employee, the system generates an S-2206 event with that effective date (also referred to as the effect date in this section).

  Note: If the action and reason of the added row is not used for collective agreement, an S-2206 event is generated without the effect date.

  If the employee was hired before the begin date of the contract revision, the effective date of the job data row should be set as the same as the begin date.

  If the employee was hired after the begin date of the contract revision, the effective date of the job data row should be set as the same as the hire date, and the effective sequence to 1.

  If other effective-dated job data rows exist after the begin date, the effective sequence of these rows must be adjusted in order for the retroactive payroll calculation to be done properly.

  The S-2206 event captures information such as the effect date ({dtEf} tag), alteration date ({dtAlteracao} tag, the system date of the action and reason setup that is specified for collective agreement), contractual change description from the union revision setup ({dscAlt} tag), and new salary amount ({vrSalFx} tag).

• Note that retroactive salary payments are reported in S-2206 events with corresponding effect dates ({dtEf} tag). For other updates of employees (for example, job code changes, shift changes and so on) that also use the S-2206 event layout to report to the Government but are unrelated to union-specific retroactive salary change, the system captures the updated value from the job data row that has the maximum effective date for the month when the change took place, and reports it without an effect date ({dtEf} tag).

• If the system is supposed to generate an S-2206 event for a newly added employee job data row but the required union information is missing, mapping errors are returned so that the administrator can take appropriate actions.

• For any salary update in job data rows that took place during the specified union revision period, no S-2206 events are generated if the compensation change percent value is equal to or less than zero. This scenario applies when the S-2206 event that was generated for the newly added salary change row is pending, and subsequent effective-dated rows are updated with the new salary amount as well but the change percent remains zero.

• The Government can accept more than one S-2206 event with the same alteration date, as long as the effect dates are different.

General Rules

Here are several general rules that apply to the Worker Health Monitoring – ASO event:

• To activate S-2210 event reporting for companies:

  • The eSocial functionality has to be enabled on the eSocial Parameters BRA Page.

  • Companies must be enabled and configured using the Company Parameters component.

  • The S-2210 event must be activated on the Events Activation Page and listed on the Non Periodic Events Page, and not to be inactivated in companies’ parameter setup.

• An Accident at Work Communication (CAT) event is triggered when a work incident or injury is reported using the Injury Details BRA or Incident Details BRA component with the Accident incident type, and the incident date entered is equal to or greater than the Health/Safety Go Live date. No S-2210 event is generated if either condition is not met.

Scenarios

Here are several examples that describe the behaviors of the Accident at Work Communication event:

• For each Accident incident row, do not enter more than one row for the Death Communication or Initial CAT type in the CAT Information section. Multiple rows are supported for the Reopened CAT type.

• If the injured employee works for multiple companies, the system submits an S-2210 event to each one of them.

• When the system creates an S-2210 event for an incident with the Reopened or Death Communication CAT type, it takes the receipt number from the latest S-2210 event that was submitted for the same incident with the Initial CAT type, and populates the value in the nrRecCatOrig tag of the new event.

  For example, an S-2210 event was created and submitted to the Government two months ago for an incident with the Initial CAT type. A month later, the system submitted a rectification for the same event to the Government. Now, as the system creates an S-2210 event for the same incident row with the Reopened (or Death Communication) CAT type row, it takes the receipt number that it received for the rectification from the Government, and populates it in the nrRecCatOrig tag of the new event.

• If a work accident results in an absence of the injured employee, an S-2230 - Temporary Absence event needs to be submitted as well. Customers need to report absence for the employee on the Absence Event BRA page so that the temporary absence event can be created accordingly.

• If changes are made to work accidents that were reported using the Injury Details BRA or Incident Details BRA component, the system sends rectifications for corresponding S-2210 events. The same is true for sending exclusion events for S-2210 events, if work accidents were excluded from associated components.

• If an S-2210 event happens to be rectified or excluded, any S-2230 event created as a result of it needs to be rectified or excluded as well. This is not done automatically and customers need to make the change in absence on the Absence Event BRA page.

General Rules

Here are several general rules that apply to the Worker Health Monitoring – ASO event:

• To activate S-2220 event reporting for companies:

  • The eSocial functionality has to be enabled on the eSocial Parameters BRA Page.

  • Companies must be enabled and configured using the Company Parameters component.

  • The S-2220 event must be activated on the Events Activation Page and listed on the Non Periodic Events Page, and not to be inactivated in companies’ parameter setup.

• To support S-2220 event reporting, the system changes the display of person ID to employee ID in each ASO exam result on the ASO Exam Results BRA Page and prepopulates the employee record number with the value from the employee’s job data. If the person ID does not have a corresponding entry in the Job Data component (for example, an individual took the exam before hired by the company formally), the system populates the default value of 0 in the Empl Record field. When the job data is created later for the individual after the hire is completed, and the corresponding employee record number is not 0, it is the company’s responsibility to make the correction on the ASO Exam Results BRA page accordingly

  Prior to implementing the S-2220 event, run a one-time process on the ASO Exam Procedure Page to update employee record numbers in exam results as needed, so that the exam information can be processed properly.

• A Worker Health Monitoring – ASO event is triggered when the ASO medical exam result of a worker is reported in the ASO Exam Results BRA component, the ASO date entered is equal to or greater than the Health/Safety Go Live date (for example, January 1, 2019), and that the worker belongs to an employee classification that is specified on the Labor Regime page.

Scenarios

Here are several examples that describe the behaviors of the S-2220 event when ASO exam results are entered, updated, or deleted from the PeopleSoft system after the Health/Safety Go Live date:

• When an ASO exam result is added to the ASO Exam Results BRA Page for a worker, the system creates an S-2220 event using information from the exam result. In addition, it also captures information from the worker’s job data for the event, for instance:

  • If the exam type is Hire, the system takes the information needed from the job data row with a Hire action that is configured for eSocial on the Hire Action/Reason Page.

  • If the exam type is Job/Position Change, Periodical, Return to Work or Specific Monitoring, the system takes the information needed from the latest job data row of the worker.

  • If the exam type is Termination, the system takes the information needed from the latest job data row with a Termination action that is configured for eSocial on the Termination Action/Reason Page.

• When a retroactive ASO exam result (for example, a periodic exam) is added for a worker and its ASO date is not the latest of all the rows, the system generates an S-2220 event with information from this exam result and the latest job data row of the worker.

• If data (for example, ASO date, exam type, order of exam and so on) is changed in the latest ASO exam result that is sent to the Government, the system rectifies the S-2220 event for the latest ASO exam with the updated information.

• If a worker changes the employee category in a new job data row, and an ASO exam is performed and its result added as a result of the job function change (as required by the new job function), the system generates an S-2220 event with information from this exam result and the latest job data row of the worker.

  Similarly, if a worker changes the employee category in a new job data row, and this time, some data (for example, the ASO date and result indicator) in the existing Hire exam result is updated. In this case, the system rectifies the S-2220 event for the hire ASO exam result with the updated data as well as information from the Hire job data row.

• If a worker transfers to a new company, two job data rows are added for the worker: one for terminating the worker from the old company and the other for hiring the worker to the new company in the transfer. An ASO exam is performed as a result of the job function change (as required by the new job function). In this scenario, the system creates an S-2220 event with information from this exam result and the latest job data row of the worker.

  If data is updated in the ASO exam result for the job function change, the system rectifies the S-2220 event for the job change exam result with the updated data, and the information from the latest job data row of the worker.

  Now if the ASO exam result row for the job function change is deleted, the system generates an S-3000 event for the information to be removed from the Government as well.

• A worker can have more than one employment within a company or in different companies. When the first job data row is added (employee record = 0) and an ASO exam result for this hiring is added to the ASO Exam Results BRA page, the system creates an S-2220 event with information from this exam result and the Hire job data row for employee record 0. Later, when the second job data row is added (employee record = 1) and another ASO exam result row for this hiring is inserted, the system creates an S-2220 event for the second employment with information from this new exam result and the Hire job data row for employee record 1.

  If a periodic ASO exam result is added for both employee records, the system creates an S-2220 event for each employee record, using the exam result and information from the latest job data row for the corresponding employee record.

• If the ASO date of an ASO exam result row is updated to a date that is earlier than the Health/Safety Go Live date, or if an ASO exam result row is deleted (whether or not it is the latest row for the worker), the system creates an S-3000 event to remove the ASO exam result from the Government.

General Rules

Here are several general rules that apply to the Toxicological Exam for Professional Drivers event:

• To activate S-2221 event reporting for companies:

  • The eSocial functionality has to be enabled on the eSocial Parameters BRA Page.

  • Companies must be enabled and configured using the Company Parameters component.

  • The S-2221 event must be activated on the Events Activation Page and listed on the Non Periodic Events Page, and not to be inactivated in companies’ parameter setup.

• A Toxicological Exam for Professional Drivers event is triggered when the drug test of a worker is reported on the Drug Test BRA Page, the exam date (or expected termination date) entered is equal to or greater than the Health/Safety Go Live date, and that the worker belongs to an employee classification that is specified on the Labor Regime page.

Scenarios

Here are several examples that describe the behaviors of the S-2221 event when drug tests are entered, updated, or deleted from the PeopleSoft system after the Health/Safety Go Live date:

• When a drug test is added on the Drug Test BRA Page before hiring or terminating a worker, the system generates an S-2221 event with information from the drug test itself, and the job data of the worker. If the worker is associated with multiple job data rows, the system takes the data it needs from the row with an effective date that is either equal to, or (immediate) greater than the exam date. If all job data rows happen to have an earlier effective date than the exam date, the row with the greatest effective date will be used.

• If the occupation code that is specified in the worker’s job data row on the Job Information Page does not require exam to be taken, a mapping error will be generated and the system cannot create an S-2221 event until the error is resolved.

• Drug tests are valid for a period of time and can be reused if time permits. Suppose that a drug test is added for a worker in preparation for hiring, and an S-2221 event is submitted to the Government. The employment is terminated a month later. If the employer confirms that the drug test (used for hiring) is still valid, the same drug test information can be added to the system for the terminated worker under the Termination exam type. The system rectifies the S-2221 event (created for hiring) with termination information and sends it to the Government.

• If the worker refuses to perform a drug test before termination, the system uses the expected termination date that is specified on the Drug Test BRA page to be the exam date for the S-2221 event.

• If data (for example, the exam date) is changed in a worker’s drug test after it’s submitted to the Government, the system rectifies the S-2221 event with the updated information. In the case where the exam date is changed to a date that is earlier than the Health/Safety Go Live date, the system creates an S-3000 event to remove the drug test from the Government as the information is no longer relevant.

• A worker can have more than one employment within a company or in different companies. When the first job data row (employee record = 0) and a drug test for this hiring are added to the HCM system, it creates an S-2221 event with information from the drug test and corresponding job data row for employee record 0. Later, when the second job data row (employee record = 1) and another drug test for this hiring are inserted, the system creates an S-2221 event for the second employment with information from this other drug test and corresponding job data row for employee record 1.

• If a drug test (which was previously submitted to the Government) is deleted from the Drug Test BRA page, the system creates an S-3000 event to remove the drug test information from the Government. If the deleted drug test has never been submitted to the Government (for example, the exam date is earlier than the Health/Safety Go Live date), no event will be generated.

• Any change to drug test-related information outside of the Drug Test BRA page, such as change of occupation code in job data, does not trigger the creation, rectification, or exclusion of S-2221 events.

General Rules

Here are several rules that apply to the Temporary Absence event:

• For absences that are caused by accidents at work and last shorter than 16 days, or absences that are not caused by accidents at work and last between three to 15 days, they need to be reported by the seventh day of the month following the absences or before the submission of payroll events, whichever happens first. Generally, other absence types follow the same rule—report either by the seventh day of the month following the absences, or before payroll events (or termination events if applicable).

  Employers may submit absence reporting to the government as soon as the day after the absence begins or when the employee has returned from absence, except for vacation.

• For absences that are caused by accidents at work or grievances and last longer than 16 days, they need to be reported by the 16th day of the absence.

• If an employee is absent multiple times for the same incident (accident at work, grievance, or sickness), and the total sum of absence days is more than 15 days within a period of 60 days, the employer must report to eSocial by the 16th day of the absence.

• For vacation absences, they can be reported eSocial 60 days prior to the vacation start and end dates.

• If an employee on temporary absence has more than one job, an S-2230 event is submitted for each of the employee’s EMPL_RCD.

• Setup on the Absence Legal Codes Page and Absence Take and Reason Page is required for temporary absences to be submitted for eSocial reporting.

• Temporary absences events are sent in chronological order by absence begin date. As for S-3000 - Event Exclusion events for temporary absence, they are sent in descending order by absence end date and absence begin date.

• Temporary absence events are set to Action Required in the error handling system if the begin or end date of absences fall within the monthly close period. The same is true for exclusion events that are created for these temporary absence events.

• If the receipt number for the original event of a rectification or exclusion event is missing, the event is placed hold on and reprocessed until the receipt number is identified.

General Rules

Here are several general rules that apply to the Environmental Working Conditions event:

• For S-2240 events to be generated and submitted properly for companies:

  • The eSocial functionality has to be enabled on the eSocial Parameters BRA Page.

  • Companies must be enabled and configured using the Company Parameters component.

  • The S-2240 event must be activated on the Events Activation Page and listed on the Non Periodic Events Page, and not to be inactivated in companies’ parameter setup.

• The S-2200 and S-2300 events must be processed and submitted to the Government already.

• An Environmental Working Conditions event is triggered whenever a working environment, activity, or condition of a worker is reported in the Worker’s Conditions BRA component, the effective date entered is equal to or greater than the Health/Safety Go Live date (for example, January 1, 2019), and that the worker belongs to an employee classification that is specified on the Labor Regime page.

  Note: For initial loading, the process takes the working conditions record of each eligible worker with an effective date that is either the same as the go-live date, or is the most current as of the go-live date, and generates S-2240 events.

Initial Loading

The S-2240 event is a non periodic event that is also included in the initial load process for employee data (GPBR_ES_ILE). When the initial load process runs for the S-2240 event and a company, the system generates an S-2240 event for the worker’s conditions record of each eligible worker that is associated with that company. If a worker has multiple worker’s conditions records, the process takes the one with the same effective date as the company’s Health/Safety Go Live date if available, or the one with the most current (maximum) effective date as of the go-live date, to be used for initial loading.

Online Transactions After Initial Loading

Here are several examples that describe the behaviors of the S-2240 event when worker’s conditions are created, updated, or deleted from the PeopleSoft system after initial loading process is completed:

• When a worker is hired, rehired, transferred to a company, or has a different worker condition (for example, a new workplace, a new work activity, a new work hazard, a new protection equipment and so on), Oracle recommends that you add a worker’s conditions record (or an effective-dated row) to the Worker Conditions Page to capture the information for the worker as soon as possible. When that happens, the system creates an S-2240 event using information from both the worker’s conditions record, and the worker’s current job data row. For instance, you add a worker’s condition record for a worker who just got hired. When the system creates an S-2240 event, it uses data from the worker’s condition record and the hire job data row, which is current as of the effective date of the worker’s condition record.

• When a worker’s conditions record is added for an employee who works at a service taker location, the system generates an S-2240 event for it using information from the worker’s conditions record, current job data, and current payee parameters (where the employee is associated with one or more service takers). The system generates a mapping error and cannot create an S-2240 event if:

  • The employee does not associate with a service taker on the Payee Parameters Page.

  • The employee is associated with a service taker on the Payee Parameters BRA page, but there is no Service Taker Establishment workplace code specified on the Worker Conditions page for the employee.

  • The employee is associated with a service taker on the Payee Parameters BRA page, and a Service Taker Establishment workplace code is specified on the Worker Conditions page for the employee, but the service taker is not listed on the Workplace Table BRA Page.

• When a worker’s conditions record is added with an retroactive effective date (for example, August 1, 2019 and the current effective date is September 1, 2019) for a row that is added on the Payee Parameters page for the same retroactive effective date, the system generates an S-2240 event using information from this worker’s conditions record, and the worker’s job data row and payee parameters row (for example, service taker) that are current as of the retroactive effective date.

• If, after initial loading, a worker’s conditions record is added, and:

  • The record has a retroactive effective date (for example, June 1, 2019) that is earlier than the effective date of the record used in initial loading (for example, June 20, 2019) and the go-live date, no event will be created.

  • The record has a retroactive effective date (for example, June 30, 2019) that is later than the effective date of the record used in initial loading (for example, June 20, 2019) but earlier than the go-live date, the system rectifies the S-2240 event for the initial loading with information from the worker’s conditions record that has the retroactive date.

• If a worker’s conditions record is added after the worker is terminated (the record’s effective date is greater than the worker’s termination date), no event will be generated.

• Suppose that a worker’s conditions record is created after a worker is transferred to a different establishment of the company and an S-2240 event is submitted to the Government to report the change.

  • If updates are made to the worker’s conditions record (the one added for the transfer, with an effective date of August 1, 2019 for example), the system rectifies the S-2240 event for the modified worker’s conditions record with the updated data, and the information from the worker’s current job data row as of the August 1, 2019 effective date.

  • If updates are made to the worker’s conditions record (the one before the transfer, with an effective date of January 1, 2019 for example), the system rectifies the S-2240 event for the modified worker’s conditions record with the updated data, and the information from the worker’s current job data row as of the January 1, 2019 effective date.

• A worker can have more than one employment within a company or in different companies. When the first job data row (employee record = 0) and a worker’s conditions record are added for the worker, the system creates an S-2240 event with information from this worker’s conditions record and the Hire job data row for employee record 0. Later, when the second job data row (employee record = 1) and another worker’s conditions record are inserted, the system creates an S-2240 event for the second employment with information from this worker’s conditions record and the Hire job data row for employee record 1.

• If a worker’s conditions record (previously submitted to the Government) is deleted, the system creates an S-3000 event to remove it from the Government’s system.

• If a worker’s conditions record (the one used in initial loading) is deleted, the system rectifies the S-2240 event for the initial loading with information from the worker’s current worker’s conditions record as of the go-live date.

General Rules

Here are several rules that apply to the Termination Previous Notification event:

• When you enter a notification date and option of a prior notification (also referred to as previous notification) for the first time on the Termination Parameters page for an employee, the system creates an S-2250 event using the notification date and submits the information to the Government. The same rule applies when you add a new row with a new begin date, and enter prior notification data in that row for the first time.

  However, if there are multiple rows for an employee in the system, and you enter prior notification data for the first time in a row that does not have the most current begin date, no event is created. Suppose that you decide to delete the current row later, which makes the row with prior notification data the one that has the most current begin date in the system. In this case, the system creates an S-2250 event for the notification date of this current row.

• Once prior notification data of an employee is submitted to the Government, any change to it triggers the rectification of the corresponding S-2250 event. For example:

  • You update the prior notification data in the only data row that exists for an employee.

  • You add a row with a new begin date and enter the same prior notification data as the previous row.

  • You add a row with a new begin date and enter a different notification date.

    In this scenario, the system checks if an S-2298 - Employee Reinstatement event was created for the employee after the notification date of the previous row.

    If yes, it means that the employee received a prior notification and was terminated before the reinstatement. In this case, the system needs to create a new S-2250 event for the new notification date and submits the information to the Government.

    If no, the corresponding S-2250 is rectified.

  • Two data rows are available for the employee. Both rows contain prior notification data and the information of the most current begin date is submitted to the Government. If you delete the current row, the system rectifies the corresponding S-2250 using the notification date of the only row that is left in the system.

  However, if the prior notification data update is made in a row that does not have the most current begin date, no event rectification occurs.

• When you delete prior notification data that is already reported to the Government, the system creates an S-3000 - Event Exclusion event to remove the information from the Government side as well. For example:

  • You delete the prior notification data from the only data row that exists for an employee.

  • You delete the row that has the most current begin date and contains the notification data that is submitted to the Government. The row with the most current begin date left for the employee does not have any prior notification data.

  • You add a row with a new begin date and clear all prior notification data from this new row.

  However, if the prior notification data is deleted in a row that does not have the most current begin date, no S-3000 event is created.

• When you enter a date and reason to cancel a prior notification that is already submitted to the Government, the system creates an S-2250 event using the cancelation date that is specified. After the S-2250 event for the cancelation is submitted successfully, do not delete or change that cancelation data from the row (or delete that whole row) because it will generate exclusion or rectification events. The Government does not accept the exclusion or rectification of events that have already been canceled.

General Rules

Here are several rules that apply to the Employee Reinstatement event:

• It applies to employees with employment relationships (employees are associated with employee classifications that are specified on the Labor Regime Page, with a specific work type.

• It applies to terminated employees only.

  If an employee was terminated before eSocial becomes effective, and the employee was not included in the S-2200 - Employees Initial Load and Hiring event that was submitted to eSocial, the S-2200 event has to be submitted again, where that the <desligamento> section is filled with the termination date of the employee, and be accepted by eSocial prior to sending the S-2298 event.

  If an employee was terminated after eSocial becomes effective, the S-2299 - Termination event has to be submitted for the employee before S-2298 event can be sent to reinstate the employee.

• It captures information about employees to fill the <infoReintegr> section of the event layout in the Additional Information BRA component.

  See (BRA) Providing Additional Information for Brazilian Employees

• Employees are not specific to or keyed by company, and can work for more than one company at a time. Therefore, any personal data change (personal data table are keyed by EMPLID) of an employee needs to be submitted to eSocial for all companies with which the employee has employment relationships.

  Job data is keyed by EMPLID and EMPL_RCD. With that, changes in job data need to be submitted to eSocial for the company associated with the employment record. If the employee has multiple employment relationships, the same number of S-2298 events need to be generated. In those events, the personal data section remains the same, the job data section, however, contains data that is distinct for each relationship.

• If the only component or table that was updated for an employee is not effective-dated, and the maximum effective date for all components and records that are used to generate the S-2298 event is earlier than or equal to (< or =) the employee’s hire date, a rectification event needs to be generated for the S-2298 event.

General Rules (Termination With or Without Payment Calculation)

Here are several rules that apply to the Termination event (with or without payment calculation):

• When a new effective date is entered in the Job Data component for a termination action and reason of a worker, the system identifies the type of employment relationship (employee or non-employee) that the worker has with the company. To do that, it takes the employee class from the job and looks up the work type for that employee class on the Labor Regime BRA page. If the employee class from the job is not set up on the Labor Regime BRA page, no driver data or trigger for the termination will be created. If the employe class setup is available, and the selected work type is CLT, the worker is an employee; if a different work type is specified, the worker is a non-employee.

  Next, the system checks if the specified action and reason on the job is associated with a termination legal code (which indicates whether or not payment calculation is required) and an eSocial event on the Termination Action/Reason page.

  When the information is available, the system adds new driver data for this termination using the appropriate eSocial event (S-2299 or S-2399), if the data hasn’t been inserted already.

• Termination events are processed on the eSocial Termination Events Page. When the termination event AE process is triggered on the run control page, it performs checks to make sure that the selected companies are active for eSocial reporting, the specified competency period is equal to or comes after the Adhere to eSocial date (month and year) and is not closed for periodic events, and the selected events are active. If any of these checks fails, the process stops and information is logged.

  Both S-2299 and S-2399 events are selected by default on the run control page and cannot be deselected.

  The Prepare Data option is the first processing option for S-2299 and S-2399 events. In this step, driver data that matches the selection criteria is loaded to staging tables, getting ready for XML files to be generated.

• Information that is saved in different pages regarding an employee’s termination is used for the generation of one Termination event only. For example, in addition to the Job Information page, the Termination section of the Termination Parameters Page is also used to capture text information or comments about terminations. If the begin date of the information on the Termination Parameters page is earlier than or equal to (< or =) the effective date of the termination action on the Job Information page for an employee, information from both pages is used to generate a Termination event for the employee.

• When a change is made to a termination row in the Job Data component for an employee, the system checks if an existing event for the same event code, employee (CPF number) and competency period is available. If yes, instead of generating a new event, the existing event is rectified if the event is already submitted to the government.

  In order to rectify a submitted event, the event’s receipt number must be present. The rectification event needs to be put on hold if the receipt number is not available.

  If an existing event is available but it’s not yet submitted to the government, the system updates the driver data for the changed row.

• If a change in termination reason is made in the Job Data component for an employee, the system compares the old action and reason with the new values and see if they reference the same eSocial event. If they refer to the same eSocial event and the event doesn’t require calculation, the existing Termination event is rectified. However, if the new values reference an eSocial event that requires calculation, submit an S-3000 - Event Exclusion event to the existing event.

• If a row for the termination action is deleted from the Job Data component for an employee, submit an S-3000 event to the existing termination event if it is already submitted to the government. If the event is not yet submitted to the government, the system removes the driver data for the deleted row.

• If a termination is triggered after a period is closed, and the corresponding termination event setup does not allow submission after closed period, no Termination event is created. An error message is logged so that appropriate actions can be taken.

For terminations that require payment to be calculated based on associated wage types tables and submitted to the government through termination events, additional setup is needed so that appropriate information can be gathered for the calculation:

• For termination types that require payment calculation, set the corresponding termination legal codes to require calculation on the Termination Legal Code page.

• Specify earnings and deduction elements to be used for termination payment calculation on the Wage Types Table page of the Wage Types Table component.

• Specify run types with the Termination or Term Non Empl payment type for termination processing on the Run Types page of the Wage Types Table component. This information is used to identify calendars to be used in termination payment calculation.

• Specify alimony elements and health data elements to be used in termination payment calculation.

  Alimony elements are specified on the Wage Types Table page, with an alimony-related income tax type value: 51, 52, 53, 54, or 55.

  Health data elements are specified on the Health Data page.

  Alimony and health data amounts are reported in termination events the same way the termination results are recorded on the Earnings and Deductions page—alimony in total amount and health data amount broken down by element.

• Associate wage types tables with companies on the Company Details BRA page.

Logs will be created to capture issues found in the setup for termination processing.

General Rules (Termination With Payment Calculation)

Here are several rules that apply to the Termination event (with payment calculation):

• To process termination events that require payment calculation, the AE process needs to identify applicable calendars to be used in the calculation. A calendar is selected if it meets all these requirements:

  • It is finalized.

  • It pertains to a company and competency period that is specified in the Selection Criteria section of the eSocial Termination Events page.

    The period of the calendar is the same as the competency period that is specified as selection criteria.

  • It pertains to a run type that is specified on the Run Types page with the payment type set to either Termination or Term Non EMPL (termination for non employees), and that run type is linked to one of the selected companies through wage types tables on the Company Details BRA page.

  Identified calendars are listed on the eSocial Processed Calendars - eSocial Termination Events Page after the AE process is run.

• To process retroactive adjustments for employees, information must also be provided in the Union Contract Revision section of the General Parameters Page for the retroactive calculation to happen.

• Global Payroll for Brazil supports the S-2299 (or S-2399) event reporting of employees who have multiple employment relationships with different companies (companies that may or may not use Global Payroll for Brazil for termination event reporting).

• The mass termination simulation functionality is an offcycle payroll process that provides payroll personnel an estimate of the costs (termination pay) incurred in case of a workforce reduction. If the offcycle calendars created for a simulation are applied to payroll, the AE process takes them into consideration when it is in the process of identifying applicable calendars to be used in the termination payment calculation. If these offcycle calendars are not applied to payroll, they will be not be considered for the termination event processing.

  For employees that are identified, driver data is added so that termination events can be created for them when the AE process runs. If an S-1200 event has already been created for the same period when the mass termination occurred, exclude the S-1200 event (if it is submitted to the government), or delete the event’s driver data (if the event has not been sent to the government).

• Wage parcel and nature of indemnity payments pertaining to terminations of employees are to be reported using the S-1210 event.

General Rules

Here are several rules that apply to the Workers who have no employment relationship - Begin event:

• It applies to employees without employment relationships (employees are associated with employee classifications that are specified on the Labor Regime Page, without a specified work type. It is triggered when the Hire action is selected in the first row of job data for an employee without employment relationship.

• It reports the employee data row with the most current effective date that is either earlier than or equal to (< or =) the eSocial on PeopleSoft date.

• For an employee to be included in the report, the employee’s hire date needs to be equal to or later than (= or >) the Company creation date, as well as equal to or earlier than (= or <) the eSocial implementation date.

  Information of employees who are hired after the eSocial implementation date needs to be submitted using either the S-2200 or S-2300 event.

• The eSocial Reg. Number field value on the (BRA) Additional Information BRA Page is required for employees with employment relationships.

  Employees are not specific to or keyed by company, and can work for more than one company at a time. Therefore, any personal data change (personal data table are keyed by EMPLID) of an employee needs to be submitted to eSocial for all companies with which the employee has employment relationships.

  Job data is keyed by EMPLID and EMPL_RCD. With that, changes in job data need to be submitted to eSocial for the company associated with the employment record. If the employee has multiple employment relationships, the same number of S-2200 events need to be generated. In those events, the personal data section remains the same, the job data section, however, contains data that is distinct for each relationship.

• If the only component or table that was updated for an employee is not effective-dated, and the maximum effective date for all components and records used to generate the event is earlier than or equal to (< or =) the eSocial implementation date, a rectification event needs to be generated for the S-2300 event.

• An update in the CPF national ID, PIS, or birth date of an employee is considered a critical change. When it occurs, a rectification is generated for the S-2200 or S-2300 event as appropriate.

• If the update is made in the company or employee class in the employee’s job data, an S-3000 - Event Exclusion event is generated for the corresponding event, followed by a new initial loading event for the employee.

General Rules

Refer to the General Rules section of the S-2205 - Personal Data Changes event for rules that are applicable to this event as well..

Hire Exclusion

Sometimes, companies need to generate exclusions for hire events to have the hiring information removed from the government when:

• The corresponding hires fail through and no longer exist.

  When that happens, administrators can run the process on the eSocial Hire Exclusion Page to generate driver information of exclusions for these hire events. Then, prepare data and create XML files for the exclusion events on the eSocial Non Periodic Event Page to be submitted to the government.

• An employee updates:

  Note: The employee information discussed in these scenarios is considered key information to the government. The system reports changes of key information through the exclusion of existing events and generation of new events, rather than the rectification of existing events.

  • The eSocial register number on the Additional Information BRA page.

    In this scenario, the system first generates an exclusion event for the employee’s existing hire event, and then generates a new hire event with the new eSocial register number.

  • The company on the Work Location page.

    In this scenario, the system first generates an exclusion event for the employee’s existing hire event, and then generates a new hire event with the new company.

  • The employee class from an employee one to a non-employee one (or vice versa) on the Job Information page.

    In this scenario, the system first generates an exclusion event for the employee’s existing hire event (for example, S-2200), and then generates a new hire event that matches the new employee class (for example, S-2300).

    No exclusion or hire events will be generated, if the old and new employee classes belong to the same employee type.

PeopleSoft HCM provides the ability to delete employment record numbers (ERNs) when these numbers are created in error or are not no longer in use. For eSocial to work properly, you need to configure the system to exclude a number of eSocial tables from this process on the ERN Delete Exception Tables Page. These tables are:

• GPBR_DRVABS_XRF (Exception Type: Exclude, Person ID Field Name: EMPLID; Empl Record Field Name: EMPL_RCD)

• GPBR_DRVCAT_XRF (Exception Type: Exclude, Person ID Field Name: EMPLID; Empl Record Field Name: EMPL_RCD)

• GPBR_DRVCMP_XRF (Exception Type: Exclude, Person ID Field Name: EMPLID)

• GPBR_DRVEMP_XRF (Exception Type: Exclude, Person ID Field Name: EMPLID; Empl Record Field Name: EMPL_RCD)