eSocial: understand how to send data to the approval environment

With the release of access to the eSocial test environment to companies of all segments since August 1st, many doubts have arisen regarding the sending of data to the approval environment.

 

The testing period allows companies to prepare themselves before the mandatory submission of events - whose first wave is scheduled for January 1, 2018. Many managers have asked us about the procedure to be performed in sending data and, therefore, , we decided to list some clarifications and guidelines regarding the setting with terms and processes that they will use on a daily basis. The idea is to help managers get used to the new terms and processes they will use.

 

Remember: eSocial will not provide a test environment in the web format (with an interface) as we have today in the access of the domestic employer. To carry out tests, companies must use their own systems, which will communicate with eSocial via Web Service, according to guidelines for developers in the Restricted Production area.

 

 

Understand what to do before sending events:

 

1. Employee registration qualification: validating basic information (such as CPF, PIS, Date of Birth and the full and correct name of the employees) will avoid many problems at the time of transition, not to mention that it will update all the data of the company's staff.
 

2. Sanitation of the database: the data to be sent must be in accordance with the current situation of the employees and with the standard tables made available by eSocial. This step must be handled carefully, as sending out-of-date or inconsistent data may cause future problems. To know more, access this content, available on the Senior website.  

 

 

Know which events to send first:

 

1. S-1000: in this event, the information of the employer/taxpayer/public body is provided and our recommendation is that the other events are sent only after the validation of this event. 
 

2. Initial and table events: are those responsible for information that will validate periodic and non-periodic events, used as a basis for composing information from other eSocial events, such as S-1010, S-1020, S-1030 and s-1050, between others. At this point, if there are discrepancies between the customer's database and what is expected by the government environment, the user must make the necessary adjustments before proceeding with the process of sending the other events. 
 

3. S-2100: this event refers to the Initial Registration of the Bond and, with the publication of version 2.3 of eSocial, it will be replaced by the event S-2200 – Initial enrollment of the bond and admission/entry of worker. While the change does not take place, the Governance environment continues to validate the S-2100 event.
 

4. Other periodic and non-periodic events: once the information base has already been sent and validated, all other periodic and non-periodic events, such as S-1200, S-1210, S-2206, S-2210, S-2230 , among others, can be sent. 
 

5. S-1299: this event is intended to inform the end of the transmission of periodic events in a certain calculation period.
 

6. S-1295: this event will only be released in version 2.3 of eSocial and was created as a contingency solution in case the company is unable to close periodic events through S-1298, which must be used to reopen a transaction of a period that has already ended.
 

7. Totalizing events: after sending the periodic events, the totalizing events S-5001, S-5002, S-5011, S-5012 occur, which are the return to the taxpayer and allow the conference of charges.

 

The execution of these steps can help in the process of sending the events, but it is up to each manager to identify the needs according to the existing reality.

 

Therefore, attention:

 

1. Try to keep your system always up to date. In this way, it is possible to guarantee the complete filling of the information and the correct generation of the data to be sent in the eSocial events. 
 

2. Access to eSocial can occur via Digital Certificate (CD) – a legally valid signature that works as a virtual identity, allowing the safe and unambiguous identification of the author of a message or transaction carried out in electronic media. The CD can be requested on the Certifying Authorities website and the most commercialized types are the A1 (valid for one year and stored on the computer) and the A3 (valid for up to 5 years, being stored in a card or cryptographic token). For the issuance of the CD, it is necessary for a manager of the requesting company to go personally to a Registration Authority of the Certification Authority to validate the data filled in the request.