eSocial Engine Definitions
Warning
This documentation applies only to the module: AP.
The eSocial Engine is responsible for assembling the XML files after generating the information in People Management.
When you change the type of environment in the eSocial Settings screen (FR030DES), it is important to review the eSocial Engine settings on this screen so that the shipments are transmitted to the correct destination (eDocs URL or directory to save to disk, depending on the type of processing).
Important
To change or delete information that has already been sent to eSocial, the process must be done directly at the source of the information. In this way the system is prepared to monitor and generate the treatments automatically, sending the change layouts and exclusion.
When performing these operations manually in the database, the system does not generate the necessary pending for eSocial. This causes irreversible inconsistencies between the system database and the Government.
For this reason, it is not allowed to perform any command directly in the database without specific orientation of the Senior, especially in the tables: R030DES, R000DME, R034MAT and all with R350 * prefix.
The General Tab
The guide General is required, the settings reported in this tab will apply to all businesses.
Type of eSocial Environment
Identifies the type of environment:
- "1 - Production": This type is used to send employer data to the official eSocial database, and should be used only on the production basis.
Important
- The "1 - Production" option is not enabled by default on the system, and to use it, it must be changed a key in the system configuration files.
- This option is not allowed to perform the data exclusion, therefore, the shipments made with this type of environment are official and are subject to legal effects and inspection.
- "2 - Restricted production - Actual data": this type sends real data to the eSocial approval base, which will be validated, including with external systems, without legal effects.
This option allows you to perform data exclusion of the type-approval environment.
Important
When changing the environment type, it is important to review the eSocial Engine settings (FR000DME) so that the shipments are transmitted to the correct destination (eDocs URL or directory to save to disk, depending on the type of processing).
Type Processing
Set whether the information for eSocial will be sent by web service or by XML files saved to disk. Depending on the option selected, the system will enable the fields for web service information or file generation.
In the system the options are:
- 1 - Send to eSocial eDocs;
- 2 - Save Archive to Disk (Third Party Messenger).
When using the processing type "2 - Save File to Disk (Third Party Messenger)", all companies that will be sent to eSocial must be registered in the "Company" tab, as it will be necessary to indicate a different directory for each of them.
Note
We recommend using the "1 - Send to eSocial eDocs" option for customers using the eDocs. This option does not require Middleware or GlassFish configuration and provides better performance.
Data for eDocs
If in the processing type the option selected is "1 - Send to eSocial eDocs", this group is enabled and must be filled in.
EDocs URL
Enter the web service address defined in eDocs.
The default URL for this field should follow this format:http: // server: port /SDE/
Note
The name SDEhighlighted at the URL above is fixed and required, so it should not be changed.
Refer to the integration web service documentation for detailed information on how to use it.
User eDocs
Inform the user used to connect to the eDocs. This is the same user eDocs (Configuration> Enterprise, in the Integration tab - Web service).
EDocs Password
Enter the password used to connect to the eDocs. This is the same password eDocs (Configuration> Enterprise, in the Integration tab - Web service).
CNPJ / CPF Digital Certificate
Register the CNPJ / CPF of the digital certificate registered in the eDocs.
Data to Save to File
If in the processing type the selected option is "2 - Save File to Disk (Third Party Messenger)", this group is enabled and must be filled in.
XML Files Directory
Enter in this field the directory where the system should store the generated XML file. If this field does not have a location selected, the system will generate the files in the Engine executable folder (inside the Vetorh folder in the directory where the system is installed).
When the engine is configured to save files to disk, and there are submissions for processing, the directories Process Social and Return. In the Process \ eSocial directory will be stored the XML files that will be sent to the government. In the Return directory will be stored the return files of the eDocs, with the prefix "ESOCIAL" (example: ESOCIAL_ID1806800930000002017071915194800011.xml).
O ESocial Engine will monitor this directory, verifying if there are pending to generate, either in the sending or by the return file of the Government environment.
Important
For the Engine to be able to create the directories, it is necessary for the user to have the Read and Write permissions in these places for generating the XML files.
General data
This group is enabled regardless of the type of XML generation and must be filled in.
Generate Log Files
Tell whether the Engine should save the logs or not.
Directory of Log Files
Define the directory where the logs will be generated if the log generation option is "1 - Yes".
If a path is not given for log generation, it is generated in the engine executable folder (inside the Vetorh folder in the directory where the system is installed).
Lot size
Enter the number of files that will be sent per batch to the eDocs. The reported batch size should be between 100 and 5000.
Maximum Execution Time
Set the maximum time that the integration web service should take to process a request with the eDocs. The maximum execution time of the batch informed should be between 60 and 360 minutes.
Verification Time
Enter the time interval for the system to generate new XML file. The reported pending check time should be between 1 and 120 minutes.
Company Guide
The Company tab will be enabled after registering the information in the General tab, this tab will record the specific information of the Engine for a particular company, that is, the companies parameterized in this place can generate the XML file in a different way than the parameterized in the General tab. If parametrizations are made in this guide, they will prevail over those in the General tab.
If there is more than one company registeredeDocs in the , the Company tab must be configured for each one. This is because each company has its digital certificate, as well as the user data and password.
Company
Select the company that needs the XML file to be generated differently than the one that is registered on the General tab.
Type of eSocial Environment
Identifies the type of environment:
- "1 - Production": This type is used to send employer data to the official eSocial database, and should be used only on the production basis.
Important
- The "1 - Production" option is not enabled by default on the system, and to use it, it must be changed a key in the system configuration files.
- This option is not allowed to perform the data exclusion, therefore, the shipments made with this type of environment are official and are subject to legal effects and inspection.
- "2 - Restricted production - Actual data": this type sends real data to the eSocial approval base, which will be validated, including with external systems, without legal effects.
This option allows you to perform data exclusion of the type-approval environment.
Important
When changing the environment type, it is important to review the eSocial Engine settings (FR000DME) so that the shipments are transmitted to the correct destination (eDocs URL or directory to save to disk, depending on the type of processing).
Type Processing
Define whether the XML files for the selected companies will be sent via web service or if the files will be saved to disk. Depending on the option selected, the system will enable the fields for web service information or file generation.
In the system the options are:
- 1 - Send to eSocial eDocs;
- 2 - Save Archive to Disk (Third Party Messenger).
When using the processing type "2 - Save File to Disk (Third Party Messenger)", all the companies that will be sent to eSocial must be registered in this tab, indicating a different directory for each of them in the "XML Files Directory" .
Data for eDocs
If in the processing type the option selected is "1 - Send to eSocial eDocs", this group is enabled and must be filled in.
EDocs URL
Enter the web service address defined in eDocs.
The default URL for this field should follow this format:http: // server: port /SDE/
Note
The name SDEhighlighted at the URL above is fixed and required, so it should not be changed.
Refer to the integration web service documentation for detailed information on how to use it.
User eDocs
Inform the user used to connect to the eDocs. This is the same user eDocs (Configuration> Enterprise, in the Integration tab - Web service).
EDocs Password
Enter the password used to connect to the eDocs. This is the same password eDocs (Configuration> Enterprise, in the Integration tab - Web service).
CNPJ / CPF Digital Certificate
Register the CNPJ / CPF of the digital certificate registered in the eDocs.
Data to Save to File
If in the processing type the selected option is "2 - Save File to Disk (Third Party Messenger)", this group is enabled and must be filled in.
XML Files Directory
Enter in this field the directory where the system should store the generated XML file. If this field does not have a location selected, the system will generate the files in the Engine executable folder (inside the Vetorh folder in the directory where the system is installed).
When the engine is configured to save files to disk, and there are submissions for processing, the directories Process Social and Return. In the Process \ eSocial directory will be stored the XML files that will be sent to the government. In the Return directory will be stored the return files of the eDocs, with the prefix "ESOCIAL" (example: ESOCIAL_ID1806800930000002017071915194800011.xml).
O ESocial Engine will monitor this directory, verifying if there are pending to generate, either in the sending or by the return file of the Government environment.
Important
For the Engine to be able to create the directories, it is necessary for the user to have the Read and Write permissions in these places for generating the XML files.
Using the eSocial Engine
Shipping via web services
Who uses web service to integrate the information with the eDocs, you will not need to generate files to save them to disk, because the information will be sent by the web service BrowseSituationDocuments.
Files saved to disk
Generating XML files
Who does not use web service to integrate the information with the eDocs, you will need to generate the XML files in the format below. These files must be saved in the "Return" folder within the directory configured in Miscellaneous> eSocial Motor Settings> field XML Files Directory.
| ID | Field | Dad | Type | Occurrence | Description |
|---|---|---|---|---|---|
| 0 | About us | 1-1 | Electronic document status | ||
| 1 | Document | 0 | 1-1 | Document identification data | |
| 1.1 | Password | 1 | Text | 1-1 | Document Key / Identifier |
| 2 | Situation | 0 | Number | 1-1 |
The status of the document must be informed. 1 - Authorized: Must be used when the government processed the shipment and returned the receipt number of the event. 2 - Rejected: Must be used when the government has processed the submission and returned identified criticism in the event. |
| 3 | Authorization Protocol | 0 | Text | 0-1 | Receipt number returned by the government for the event. Required when Situation = 1 - Authorized. |
| 4 | Message | 0 | Text | 0-1 | Summary of the situation of the event. When Situation = 2. Examples: a) Invalid event content; b) Returned with Government errors. |
| 5 | DetailsCritica | 0 | 0-1 | Generated for eSocial with bounce details | |
| 5.1 | Critical Detail | 5 | 0-N | Generated for eSocial with bounce details | |
| 5.1.1 | Cod | 5.1 | Number | 1-1 | Rejection code |
| 5.1.2 | Location | 5.1 | Text | 0-1 | Tag location with problem |
| 5.1.3 | Message | 5.1 | Text | 1-1 | Issue message |
Here is an example of authorized shipment, that is, information was sent through the layouts and the return was positive:
<? xml version = "1.0" encoding = "utf-8"?>
<LocationDocument xmlns: ds = "http://www.w3.org/2000/09/xmldsig#">
<Document>
<KeyDocument> ID1806800930000002017071917133100001 </ DocumentDocument>
</ Document>
<Situation> 1 </ Situation>
<Autostart Protocol> 1.2.0000000000000011124 </ Autostart Protocol>
</ LocationDocument>
Following are two examples of rejected submissions, that is, information was sent through the layouts and the return was negative.
Example 1:
<? xml version = "1.0" encoding = "utf-8"?>
<LocationDocument xmlns: ds = "http://www.w3.org/2000/09/xmldsig#">
<Document>
<KeyDocument> ID1806800930000002017071917133100001 </ DocumentDocument>
</ Document>
<Situation> 2 </ Situation>
<Code> 401 </ Code>
<DetailsCritical>
<Critical Detail>
<Code> 537 </ Code>
<Message> Already exists in the system registry with same identification code (key) in period of validity conflicting with the period informed in the current registry.
Suggested Action: The event can only be received if there is no other event for the table with the same identification code (key) in period of validity conflicting with the period informed in the current event.
Make sure the identification code and the periods entered are correct. </ Message>
<Localization />
</ DetailCritical>
</ CRITICAL>
</ LocationDocument>
Example 2:
<s: Envelope xmlns: s = "http://schemas.xmlsoap.org/soap/envelope/">
<s: Body>
<BrowseSituationDocumentsResponse>
<BrowseSituationDocumentsResult xmlns: a = "http://schemas.microsoft.com/2003/10/Serialization/Arrays" xmlns: i = "http://www.w3.org/2001/XMLSchema-instance">
<a: anyType i: type = "StatusDocument">
<Document>
<KeyDocument> ID1123456780000002017071115003800010 </ DocumentDocument>
</ Document>
<Situation> 2 </ Situation>
<DetailsCritical>
<Critical Detail>
<Code> 537 </ Code>
<Location> Testing </ Location>
<Message> Already exists in the system registry with same identification code (key) in period of validity conflicting with the period informed in the current registry.
Suggested Action: The event can only be received if there is no other event for the table with the same identification code (key) in period of validity conflicting with the period informed in the current event.
Make sure the identification code and the periods entered are correct. </ Message>
</ DetailCritical>
<Critical Detail>
<Code> 986 </ Codigo>
<Message> AAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA AAAAAAA AAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAA AAAAAAA AAA AAAAAAAAAAAAAAAAA.
Suggested Action: The event can only be received if there is no other event for the table with the same identification code (key) in period of validity conflicting with the period informed in the current event.
Make sure the identification code and the periods entered are correct. </ Message>
</ DetailCritical>
</ CRITICAL>
</ a: anyType>
</ BrowseSituationDocumentsResult>
</ BrowseSituationDocumentsResponse>
</ s: Body>
</ s: Envelope>
English
Español
