Você quer ler esse blog post em português? Clique aqui.
Hello,
In this blog post, I will explain how you can transmit EFD-Rein events using asynchronous communication via HTTP Client.
Prerequisites
You must have the Support Package 17 of SAP TDF installed and updated as per list of prerequisite notes for the SAP installation note:
General Definitions
Even before the new events of the 4000 series, EFD-Reinf already had an event that was asynchronous - the event R-2099. In R-2099, the event was sent, a protocol was returned, and after some time, the final return after processing on the Brazilian federal revenue service (RFB) side returned the R-5011.
From the layout R2.1.1, this form of sending is valid for all events. This means that after the events are sent, you will receive a protocol and, with this information, queries can be carried out. At a future point in time (when processing on the RFB side has been completed), the return events will be send according to the sent event.
During a few months of the current layout (currently 2.1.2), events may be sent both synchronously and asynchronously. After this period, the RFB will receive the events only in asynchronous form. This information can be checked in the Developer Guidance Manual. More details in the Developer Guidance Manual 2.2 - Capitulo 6.
Figure 1
Synchronous and asynchronous models according to the Federal Revenue Service in Portuguese
The preference of the RFB is that events are sent asynchronously whenever possible, together with the definition that only asynchronous models will be maintained. Following this preference, SAP is making available only the asynchronous format for all events since then.
Configuration Required
After applying the SAP Notes stated in the prerequisites section, be aware of the manual step in SAP Note 3305556, which explains two main points that are necessary to enable the transmission of the events: RFC creation and an adjustment to a configuration.
By opening the configuration Government Communication using Local System (/TMF/MD_SOACOMM), you can see the addition of a new column, Remote Function Call (RFC) Destination (RFC_DESTINATION).
Figure 2
Configuration details of Government Communication using Local System
If you used to send the events exclusively via SOAMANAGER, you must fill in this field with the RFC created in your system. The RFB now uses the REST protocol, which makes it impossible to use the SOAMANAGER due to incompatibilities.
Therefore, SAP delivers two ways to send the events: via HTTP Client (Creating the HTTP Client), where the destination URL is selected using an RFC as described now and the via Process Integration (PI). This second model will be delivered soon.
With this update, the following rule is applied to determine which form of communication (PI or HTTP Client).
If any line of this configuration is filled and relevant for transmission and if the RFC field is filled, the communication used is via HTTP Client, the logical port field is restricted for communication via SOAMANAGER of eSocial and leaiute 1.5.1 of EFD-Reinf.
Now, if no row is configured for EFD-Reinf for the CNPJ of the certificate or no configured entry is found following the selection criteria of the application, then the communication will be via PI.
How to Transmit the Events
Even with the news described in this blog, the overall experience of sending EFD-Reinf events through SAP TDF Messaging Framework has not changed.
The experience will indeed work as it already worked for the R-2099 event as mentioned earlier in this blog.
Below I will show you how to send EFD-Reinf events using the configuration to send the events via HTTP Client.
In this example, an R-4010 was generated.
Figure 3
R-4010 event in SAP TDF Messaging Framework
After the event is generated, you must process the transaction TDF Messaging - Flow Execution (/TMF/MF_FLOW_EXEC), this processing can be done either actively or via JOB.
Figure 4
Transaction TDF Messaging - Flow Execution
In this step, you see the difference between sending the events via synchronous and asynchronous models. In the asynchronous model, you will receive the protocol of the sent batch containing the transmitted events. It’s also possible to notice that at first, the RFB will return with the protocol plus the status 1 – The batch is awaiting processing.
Figure 5
Details of the batch sent in TDF Messaging Framework
After receiving the protocol, you will need to repeat the step of transaction TDF Messaging - Flow Execution (/TMF/MF_FLOW_EXEC) to make a query from the protocol that was sent and is currently in the batch.
In this second step, it’s necessary to fill in the Flow field with the value BATCHR.
For the Filter Steps field, two options can be used: leave the field empty or a new JOB can be created to perform the query step and maintain the events, where the Filter Step field can be filled in with the value BATCH_RESP.
Figure 6
Details of the filter used in the transaction TDF Messaging - Flow
After this process has been carried out and if the processing is completed, the batch is updated with the status 2 – Batch Successfully Processed – All Events Processed Successfully.
Figure 7
Batch successfully processed in TDF Messaging Framework
On the Batch Events tab, you can see that in addition to the events that have been sent, you can also see the return events. In the example below, R-4010 events were sent and their respective R-9005.
Figure 8
Lista de eventos enviados e de retorno no TDF Messaging Framework
We would love to have your feedback. If you have any questions or suggestions for an upcoming post, please leave your comment below. Apart from the comment section, you can also contact us through the Customer Influence platform, where you can propose ideas to improve our product, vote on previously released ideas and follow those ideas being currently implemented. Follow the SAP Tax Declaration Framework for Brazil tag here at the SAP Community to keep updated with the latest news on the TDF Add-On.
See you next time!
Rodolfo Felipe Celante
SAP TDF Development Team
#SAPGoGlobal #SAPLocalization