Você quer ler esse blog post em português? Clique aqui.

Hello.
In this blog we will continue to talk about preprocessing with an emphasis on the scenarios supported by it.
We suggest reading the following blogs to help contextualize the subject: TDF: EFD-Reinf 2.1.1 – Scenario Analysis and TDF: EFD-Reinf 2.1.1 – What's New in Preprocessing.
Prerequisites
You must have TDF Support Package 17 installed and updated as per list of prerequisite notes for the SAP installation note:
Supported Scenarios
Below, the supported scenarios will be described. Notice that not all scenarios are covered by the process; however, the following are the result of a union between SAP and several customers, and we worked together to cover the most common scenarios to facilitate the day-to-day lives of customers who need to report EFD-Reinf.
General Rules
As a general rule, to identify that the data is meant for R-4010 during preprocessing, it’s necessary that the Natural Person (LFA1-STKZN) field is marked in the vendor master data.
Figure 1
Vendor Master Data screen indicating the Natural Person field
It’s important to note that, due to the possibility of a supplier being from abroad, the CPF field (LFA1-STCD2) will not necessarily be filled in.
Another important point is that this scenario should have information in the WITH_ITEM table. This data is created automatically when the supplier has the withholding tax data registered and the process is carried out by the standard purchasing process:
Figure 2
Vendor Master Data screen with the registered Withholding Tax information
In the example above, this tax type is registered at the time of invoice:
Figure 3
Screen demonstrating the registered tax to be used at time of invoice.
With this, the system understands that preprocessing will recognize this date as the date of the generating event <dtFG> at the time of invoice posting.
Without using the BADI, it’s necessary to configure the Income Nature (/TMF/D_R_NATREND) in the SAP TDF environment. Use the fields TIPO_DOC , COD_PART, COD_CTA_DESP, NAT-REND, and NAT_REND_OBS to select the tax documents correctly and determine the nature of income as required.
To understand the configuration mentioned above and also how to determine the nature of income, visit the blog TDF: EFD-Reinf 2.1.1 – How to Determine the Nature of Income.
If the preprocessing of the accounting document has withheld tax but did not find any rule in Income Nature, the system will create a row in the Income Postings/Payments with Withholding (/TMF/D_LCTO_RENRT), but it will not fill in the NAT_REND field. In this case, we recommend the rules configured in Nature Income and/or review the implementation of the preprocessing BADi.
It’s important to note which document will be informed in the Income Nature. If both the invoice document and the clearing document are placed and the retention process is payment based, we’ll have a duplicate posting.
Figure 4
Screen for invoice document in SAP
Figure 5
Screen demonstrating a payment document in the SAP system
Figure 6
Configuration considering both Invoice and Payment documents
Therefore, it’s not recommended to put the payment document type in the configuration, only the document type of the invoice.
The line that is created can later be deleted. Assuming that the line did not exist and does not have the entry with payment document type (in the scenario document type ZP), we would expect the following result:
Note that in the Nature Income configuration, although you have entered COD_PART, the rules are:
- TIPO_DOC vs COD_PART vs COD_CTA_DESP
- DOCT_TYPE vs COD_CTA_DESP
If there is a line with only the COD_PART, this data will not be used as it is not supported at this time.
Invoice receipt with more than one item, with goods receipt and income tax recognition at time of invoice
In this scenario, for MM invoice verification, receipts have been recorded in the purchase order and later the goods receipt has taken place.
Figure 7
Purchase Order in SAP
This creates the accounting document at the time of invoice entry.
Figure 8
Invoice showcasing Accounting Document created in SAP
If we look at the accounting document of the invoice, it’s possible to identify that the offsetting against the vendor is the withholding tax accounts and the receipt transitory.
Figure 9
Accounting Document in SAP
In this scenario, note that we have the correct expense account associated with the process in the purchase order:
Figure 10
Purchase Order on SAP showcasing the G/L account
It’s important to note that a hypothetical scenario in which you have more than one G/L account for the same item is not supported in the standard system.
This happens because withholding taxes are handled at document level and, as customers debated during the solution development meetings, this scenario will not be handled in the standard way by preprocessing. If you have this scenario in your process, you must implement the BAdI to correctly handle your scenario.
On the other hand, if you have more than one cost object with the same expense account, the scenario is supported.
Figure 11
Purchase Order with two different cost objects in SAP
In this case, the system will read the field from the expense account in the purchase order to compare with the data in Income Nature in TDF.
In the next blog post, we will continue talking about the scenarios supported by preprocessing, but for the event R-4020.
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