Implementation Tips – SAP Document and Reporting Compliance, inbound invoicing option for Brazil (NF-e)
We have prepared a summary guide and implementation tips for you, customer or partner who wants to have product implementation details for SAP Document and Reporting Compliance, inbound invoicing option for Brazil (nota fiscal eletrônica). Especially if you are a customer migrating from the SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica) solution, better known as SAP GRC NFE.
The first step is to implement all prerequisite SAP Notes of the solution. All required SAP Notes are listed in the SAP Note 2776753, as explained in the image:
You need to generate the credentials to integrate your backend system (SAP ECC or SAP S/4HANA) with the cloud service. Follow the SAP Help Portal step-by-step described here as shown in the image. Remember that you need the purchased license to perform this step.
Let me present some tips to assist you in this process:
Tip 1: Only those who have access to the global account will be able to generate the credentials, you must verify in the company who is responsible for administering the global account. To give the global account access to other users, check here .
Tip 2: If the person responsible for administering the global account is no longer in the company, you can open a ticket on the BC-NEO-CIS component requesting a new access. This is a core component responsible for provisioning SAP BTP cloud services, depending on the analysis, new access will be granted.
Tip 3: Depending on how the license agreement was made, a second global account may have been generated. If this wasn’t the intention, look for the SAP commercial area to adjust the contract.
In the integration step, the backend system needs to communicate with the cloud. Check the required configuration here and on the following image as an example:
To check if the backend is communicating with the cloud, check the last step described here.
You need to make the settings described on the SAP Help Portal as shown in the following image:
For details of SPRO customization, check out here. Make sure all customizing are done, including the standard from eDocument Cockpit.
Electronic Document Processing Framework
The SAP Document and Reporting Compliance, inbound invoicing option for Brazil (nota fiscal eletrônica) uses the eDocument Cockpit monitor. This is a global monitor that is already used in several countries. The monitor has been delivered as a framework to facilitate extensibility in case of creation of new processes or adapting existing processes.
In case of receiving NF-e documents, depending on the company processes, there may be a need to extend certain processes via Framework. In these cases, it’s essential to know the by the Framework by the implementation team, especially the ABAP consultant.
In case of migration from SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica), the FLEX processes have to be replaced by new processes in the Framework. For automation of CT-e documents, the BAdIs FLEX have also been delivered, but CT-e automation can also be done via extension by the Framework.
Framework is maintained by the global team of SAP Document and Reporting Compliance, official documentation can be checked here as shown below.
Remember that the use of the Framework for document types not supported by SAP Document and Reporting Compliance, inbound invoicing option for Brazil requires an additional license.
You can activate the Receiver Acknowledgement via the EDOC_BR_MNG_DISTDFE view. Before activating, it’s important to understand the functioning of the Receiver Acknowledgement Web Service, by reading the technical note NF-e 2014.002.
If this is the case for a new implementation, where the company has never used the Receiver Acknowledgement Web Service, simply inform the NSU as zero. Then, the system will fetch all documents available on SEFAZ for the CNPJ of the requested recipient.
For a migration, the previous application must be deactivated. Check which was the last NSU processed by the application and then report NSU+1 in the view. Then, the system will ask SEFAZ for the XML files from the mentioned NSU. When you consult an NSU out of sequence, or when two applications are sending requests for the same CNPJ, it may cause the Misuse rejection.
You need to inform the NSU for the desired CNPJ, as explained on the following image:
From this moment on, SAP’s cloud service will communicate with the government’s web service to download the XML files. Notice that to effectively download the XML file, there is a process defined by SEFAZ in which a summary of the invoices issued against the CNPJ consulted must first be requested. Next, you must issue the operation acknowledgment of the event for each invoice, and then finally request the download of each XML file. You can check the status as the following image:
The “Updated NSU” column indicates in which NSU the cloud service is communicating with the government at that moment.
The “Max NSU” column indicates which is the maximum NSU returned by the government.
If the “Updated NSU” column is different from the “Max NSU” column, means the cloud is still calling the web service to get new XML files. If the columns are the same, it means that there are no more documents to download from the government.
The column “Last SEFAZ Search” indicates which was the last time the cloud communicated with the government. The purpose is that you be aware of when the last call was made. To prevent rejection of Misuse, the cloud has the following rule: if there are documents to be returned, the cloud will make the next call in 5 minutes; if SEFAZ returns that there are no more documents, the cloud will make the next call in 1 hour.
The “Total Docs” column informs you how many documents have already been downloaded from the government and which are available in the cloud. All the initial communication is between the cloud and the SEFAZ web service. The XML files will always be returned to the cloud (and not to the backend system). The company can request to download these XML files to the backend by running the EDOC_BR_DISTDFE_RETRIEVE job. This job communicates with the cloud and uploads the XML files in the eDocument Cockpit monitor, where the Business Model column will be specified as “B2G”. The job will not call the SEFAZ web service, but the cloud.
If you run the job and it has missing settings, the system may not be able to upload the XML files in the eDocument Cockpit monitor automatically. These XML files will be uploaded in a separate monitor, which can be accessed via the EDOC_BR_PENDING_DOCU transaction. You should analyze the returned XML files in this transaction, resolve the configuration errors, and then pass to the eDocument Cockpit monitor, or delete the XML files if they are no longer relevant.
For Events, it’s also possible to receive all events returned by the government, including events issued by tax authorities. For receive the events, it’s necessary to configure which are the desired events in the EDOBREVTDESCV and EDOC_BR_MNG_NFE_EVT views.
These guidelines also apply to downloading CT-e events.
You need to understand how Invoice Simulation works to understand how the system validates prices and taxes.
The system does not exactly validate the tax amount from XML files against the tax amount calculated in the purchase order, because the differences in cents (or reais depending on the company code) may occur. Because of this, many customers work with the MIRO tolerance. So if there’s tolerance set up, the tax amount will be another one so the system can’t compare exactly the same values. For example: my order has 100.00 reais net price and I allow a tolerance of 10% for plus or minus. If an XML file has a net price of 110.00 reais, the system will accept and simulate the invoice considering this price. The taxes will also be recalculated considering this new price of 110.00 reais.
The MIRO tolerance is a standard functionality of MM (Material Management) configured via the V_169G view.
When the tolerance is not configured, the system recognizes the absence of tolerance and does not perform any checks. Then, the system informs you that the NF-e is always correct. Therefore, always configure the tolerance so that the system validates the price and consequently the taxes.
The tolerance message can be configured as Warning or Error. The recommendation is to set the tolerance message as Error. Then the system identifies and returns the error at Invoice Simulation time. If this step is configured to run automatically and the tolerance message is configured as Warning, for example, the system does not indicate that there is an error and will continue with the processing of the NF-e.
Tip 1: Conditions starting with X* should be created and added to pricing, check the SAP note 1817495 .
Tip 2: To know which net price (BASB condition) and which tax rates and bases are being considered for simulation, check the “Tax Condition” tab in the Invoice Simulation.
When a debug is required, a breakpoint can be placed within the Process Manager. By selecting the process and step, you can check which class-method will be called.
You can select the proces in the SM34 transaction, opening the EDOC_PROCMGR view cluster (or the EDOP transaction, depending on backend system version). On the following image for example, the Normal Purchase process (BRNORMPRCH) has been selected.
After selecting the process, choose “Process Step” in the first item of the menu list on the left and you check all the steps of this process.
On the follow image for example, the Simulation step was selected and the Class/Method columns is the class to be called:
Migration of SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica)
On the SAP Help Portal, you can access this page to check the description of customizings/BAdIs for SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica) and their respective customizings/BAdIs for SAP Document and Reporting Compliance, inbound invoicing option for Brazil.
Below are the main views and BAdIs of SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica) and the respective view/BAdI for the inbound invoice option:
|GRC NF-e Inbound View||View DRC NF-e Inbound|
|GRC NF-e Inbound BAdIs||BAdiS DRC NF-e Inbound|
|BADI_EDOC_SOURCE_DOC > DETERMINE_DOCUMENT_TYPE|
|/XNFE/BADI_XML_VALIDATE||BADI_EDOC_SOURCE_DOC > VALIDATE_SOURCE|
Tip 1: You can extract the XML files sent by the vendor directly from an email box through SAP NetWeaver Process Integration (PI). If it’s a requirement in the inbound invoice option, you can extract these XML files through development using the standard SAP ERP SOST transaction.
Tip 2: It is recommended the XML files that are stored in SAP Electronic Invoicing for Brazil today are migrated to an external repository. You can upload old documents in the eDocument Cockpit monitor, but each document will be considered as one document processed by the licensing metric. This is not recommended considering the high cost involved due to the extreme volume.
Tip 3: The J_1BNFE_IN and the J_1BNF_MSEG_DATA BAdIs from the backend system, initially created for SAP Electronic Invoicing for Brazil, can also be used in SAP Document and Reporting Compliance, inbound invoicing option for Brazil.