1. Introduction
SAP GRC NFE is a product recently released by SAP that implements the requirements for Brazilian specific electronic invoicing scenario. It handles several communication interfaces between the company's ERP(s) system(s) and the relevant government systems; xml document handling; digital signatures for the xml documents with specific requirements from the government; B2B communication between business partners (suppliers and customers), among other functionalities.
However, in order to explain about the SAP GRC NFE solution, it's necessary to have some background on the Brazilian NF-e project (NF-e stands for "Nota Fiscal eletrônica", which is Portuguese for Electronic Invoice).
h3. 1.1. NF-e Project
[http://www.nfe.fazenda.gov.br/ | http://www.nfe.fazenda.gov.br/]
In Brazil, the NF-e project is part of a bigger government program called SPED (Sistema Público de Escrituração Digital, or Electronic Bookkeeping Public System), which is a nationwide project that intends to eliminate all (or most of) the current paper-based legal reporting activities, replacing them for electronic-based operations.
Among these, collecting all the issued invoices, sending them to the relevant parties (transporters, customers etc.) and storing them for auditioning purposes is one of the most expensive activities. The NF-e project, in particular, brought some new concepts on how the invoice issuing process shall work in Brazil from now on:
- instead of storing the paper invoices for several years, now the companies have to digitally store the electronic files which hold the NFe data and the approval data from the government;
- instead of sending/receiving paper invoices, now the companies send electronic files to their customers and receive such files from their suppliers, making it much easier to implement business to business (B2B) integrations;
- instead of the invoice following the goods transportation, now there is a paper auxiliary document, called DANFe (short for NFe auxiliary document), that describes the NFe and follows the goods (the electronic file is the document with actual legal value; the DANFe has actual no legal value, it's just a paper representation of the NFe, with a pre-defined format, for facilitation purposes).
h3. 1.2. SAP NF-e solution portfolio
In order to cover the whole NF-e project requirements, SAP offers two products in its portfolio:
h2. 2. Installation
The SAP GRC NFE product is developed over the SAP NetWeaver platform by SAP GRC (Governance, Risk & Compliance) team.
It consists of basically three logical components:
- NFE core component (ABAP Add-on): delivered within SLL-NFE Software Component;
- Digital Signature application (Java EJB): delivered within SLL-NFE-JWS Software Component;
- XI Content for the SLL-NFE Software Component, with the relevant interface objects for NFE.
The logical landscape for GRC NFE is shown below:
!https://weblogs.sdn.sap.com/weblogs/images/251792539/Landscape.png|height=447|alt=SAP GRC NFE Landscape|width=517|src=https://weblogs.sdn.sap.com/weblogs/images/251792539/Landscape.png!
The relation between logical and physical landscape is as shown below:
- the NFE Core component is installed on a SAP WAS ABAP 7.00;
- the NFE Java component is deployed on a SAP WAS Java 7.00;
- the NFE XI Content is imported on Integration Repository of SAP PI 7.0;
Technically speaking, SAP Portal is not a requirement for GRC NFE to properly work, since the user interfaces for GRC NFE are available through Web Dynpro for ABAP screens and properly delivered within the Core ABAP component, together with the relevant user roles. But since the UI is web-based, it is also a good practice to maintain it in the company's corporate portal, following SAP recommendation, for enhancing the user experience, for security purposes, etc. Whether or not to maintain GRC NFE UI in SAP Portal, that must be evaluated at project blueprint and sorted out with the customer.
For the installation of ABAP & Java NFE components, there are some pre-requisite software components, which are described in the documentation referred below:
Regarding the logistics for the installation of these Application servers, it may be evaluated the possibility of installing everything on a single instance, usually the PI instance, since it already contains both ABAP and Java Web Application Servers.
However, the formal recommendation by SAP is to not install more than one application by instance, especially in the case of SAP PI (for this recommendation, please check SAP NetWeaver 7.0 Master Guide: http://service.sap.com/instguidesNW70 -> Installation) due to the possibility of causing performance bottlenecks (because PI is a very resource-consuming application).
Nevertheless, at project time, it may be evaluated to go further with the single-instance landscape, at least for DEV and QAS systems (for which performance does not play a much relevant role), thus reducing hardware costs. But this has to be evaluated case by case (and aligned with the customer, who must be aware of the risks).
If the customer does decide for the single-instance installation, please notice that GRC NFE, as any other SAP application, needs a Business System in SLD with the Application Server role, to properly communicate with the Integration Server. Hence, it is necessary a second Business System for GRC NFE in the WAS ABAP Technical System of PI instance (meaning, a new client on WAS ABAP needs to be created, on which GRC NFE will run; the Integration Server client should remain the same).
h2. 3. Implementation
3.1. Pre-requisites
In order for SAP GRC NFE to be able to receive the necessary data from the backend system, it is necessary that the backend system is prepared to generate this data in the format that the government expects and to receive the response messages, evaluate the results and continue the sales/purchase processes accordingly. It is also necessary to create an interface between the backend system and SAP GRC NFE product so that the information can be exchanged.
In case the backend is SAP ERP (which will probably be the case for most of the implementations), the integration between SAP ERP and SAP GRC NFE is seamless, meaning that no development is necessary. The only steps which are necessary is to set the "xNFe active" flag on the NF-e specific customizing view on ERP and to create the relevant RFC destinations (from ERP to GRC NFE and vice-versa). These steps are described in details in the GRC NFE documentation (discussed below).
For SAP ERP, the necessary tools in ERP side communicate with GRC NFE are released in Support Packages (it is also possible to implement these view direct implementation of relevant SAP Notes). An overview on these requirements can be found in SAP Note 989115 . If you intend to search for the relevant notes, search for notes in the XX-CSC-BR-NFE application area (for SAP_APPL Software Component).
In case the backend is not SAP ERP, communication interfaces with SAP GRC NFE can be easily designed through SAP Process Integration to communicate with the standard GRC NFE inbound and outbound interfaces. These interfaces are RFCs on the Core ABAP component, listed below:
- /XNFE/NFE_CREATE: for incoming NF-e authorization requests;
- /XNFE/NFE_CANCEL: for incoming NF-e cancellation requests;
- /XNFE/NFE_SKIP: for incoming NF-e number skipping requests.
h3. 3.2. Documentation
In order to assist the technical consultants with implementing and configuring GRC NFE, SAP has developed an Online Knowledge Product (e-learning) delivered as a RKT (Ramp-up Knowledge Transfer) for SAP GRC NFE 1.0. It is available for free for Ramp-up customers and can be acquired by any other customers and consulting partners (for price and purchase information, please access http://service.sap.com/okp -> Preview Content Details & Buy and browse for GRC -> ONFE10 SAP GRC Nota Fiscal Electronica 1.0).
Once you've purchased it, the RKT can be directly accessed through the OKP home page, through the menu to the right (just click on SAP GRC Nota Fiscal Electronica 1.0 on the list of available OKPs).
There is also an online help for the product, available through SAP Help Portal .
h3. 3.3. Configuration
As described above, the configuration steps for GRC NFE are covered by the RKT. However, due to the product evolution, some enhancements have already been included in the Product, which were not yet reproduced in the RKT material (it will be updated in time). Meanwhile, these points which are now missing in the RKT are described below.
h4. 3.3.1. System Landscape Directory
Before the configuration of the NFE XI Content can be executed in the Integration Directory (as indicated in the RKT), some tasks need to be performed in the SLD.
As indicated above, there are two application components for the GRC NFE internal components: 1 for the Java component, 1 for the Core component (ABAP Add-on). Hence, two Business Systems (1 of type WAS Java and 1 of type WAS ABAP) are necessary in SLD, to represent these components.
Also, in order to properly configure all the scenarios (with the relevant routing conditions), it is necessary to add the NFE Product & Software Components versions to the Technical/Business Systems. You find these in the Software Catalog of SLD. The association should be as shown below.
!https://weblogs.sdn.sap.com/weblogs/images/251792539/sld_product.png|height=394|alt=NFE on SLD|width=469|src=https://weblogs.sdn.sap.com/weblogs/images/251792539/sld_product.png!
The SAP Nota Fiscal Electronica 1.0 Product Version and the nested Software Component Versions are included in SAP Component Repository Content (SAP CR Content) starting on version 3.10. To check the current SLD CR Content version, in SLD home page, go to: Administration -> Details -> +Data +tab, and check the SAP CR Content Version value.
In order to update the SAP Component Repository in SLD, please check SAP Note 669669 .
h4. 3.3.2. New Scheduling Rule for the Batch Processing Job
As of SLL-NFE SP02, a new behavior for the /XNFE/PROCESS_REPORTS report has been introduced.
Differently from what is commented on the RKT material, now this report can be scheduled as a Periodic Job, in the same way of the Service Status check Job. The Job is still executed permanently but, in case of any failures, it will be automatically restarted, thus guaranteeing a 24/7 processing without necessary human intervention.
The new functionalities also include a parallel execution control in order to avoid multiple instances of the report of being executed.
h4. 3.3.3. Schema Validation
As of SLL-NFE SP02, the NFe Schema Validation was released. This validation makes sure that no wrongly formatted data is included in the NFe XML messages. In order to activate the validation for a configured branch, just mark the "Validation" flag in the Configure System Response for Each Tax Number (CNPJ) customizing view for NFE, in SAP IMG (transaction code SPRO), as shown below.
!https://weblogs.sdn.sap.com/weblogs/images/251792539/validation_cust.png|height=149|alt=Validation Customizing|width=696|src=https://weblogs.sdn.sap.com/weblogs/images/251792539/validation_cust.png!
If an NFe sent from backend is invalidated, an automatic message is sent back to the ERP with a rejection status, so that the necessary corrective measures are taken, and the further processing steps (digital signature, batch association etc.) are not executed. In order to check the validation log (with the invalidated fields), click on the "Log Display" button of the NF-e Details screen, as shown below. A popup with the validation log will be open.
!https://weblogs.sdn.sap.com/weblogs/images/251792539/validation_monitor.png|alt=Validation Log|src=https://weblogs.sdn.sap.com/weblogs/images/251792539/validation_monitor.png!
h4. 3.3.4. BAdI for enhanced NF-e fields mapping
As of SLL-NFE SP02, it was also released a new BAdI for enhancing the mapping of the NF-e fields. The standard mapping should be enough for most customers but, for those who have custom specific rules for some fields (for example, special cases for some taxes, specific industry sector fields etc.), these can be evaluated within this BAdI.
To implement the BAdI for NF-e fields mapping, just execute the BAdI to Extend the NF-e with Feeder System Data customizing entry for GRC NFE (also accessible through SPRO), as shown below.
!https://weblogs.sdn.sap.com/weblogs/images/251792539/badi.png|height=241|alt=NFE BAdI|width=420|src=https://weblogs.sdn.sap.com/weblogs/images/251792539/badi.png!
h4. 3.3.5. Communication User Details
As of SLL-NFE SP03, two new user roles were released in order to make it easier to configure the communication between the several components of the NF-e data exchange process.
These user roles can also be created through manual steps, following the recomendations of SAP Note 1223469 .
On a simplified view, the communication process is as follows:
!https://weblogs.sdn.sap.com/weblogs/images/251792539/comm_flow.png|height=462|alt=Communication Flow|width=463|src=https://weblogs.sdn.sap.com/weblogs/images/251792539/comm_flow.png|border=0!
Each communication step is described below.
h4. I - RFC Communication between ERP & GRC NFEa) Communication from ERP to GRC NFE
In ERP, it is necessary to create a RFC Destination of type 3 (R/3), in order to send the NF-es to GRC NFE. In this RFC Destination, define a service user from the GRC NFE system which contains the /XNFE/RFCSERV role.
A dialog user can be used temporarily for debugging & testing purposes, but should be avoided for productive scenarios.
h5. b) Communication from GRC NFE to ERP
In GRC NFE, it is also necessary to create a RFC Destination of type 3. This RFC Destination must be defined with a service user from the ERP system with the necessary authorizations for the ERP processes (at least, the S_RFC & F_NFBA authorization objects are necessary).
A dialog user can be used temporarily for debugging & testing purposes, but should be avoided for productive scenarios.
There is also the necessity to associate this RFC Destination with the ERP Logical System Name (as described in the RKT), in BD97 transaction (if necessary, create the ERP Logical System Name in the GRC NFE system through BD54 transaction).
h4. II - Proxy Communication between ERP & GRC NFEa) Communication from GRC NFE to XI
In order for GRC NFE to communicate with XI, it is necessary to maintain a HTTP Destination (RFC Destination of type H) in the GRC NFE system, pointing to the XI system. It needs to have the path prefix as /sap/xi/engine?type=entry.
This HTTP Destination should use the PIAPPLUSER in order to log on PI.
Then, define this HTTP Destination in SXMB_ADM ->
Integration Engine Configuration, in the Corresponding Integration Server field, in the format "dest:// http://<server>:<port>/DigitalSignature/ws?style=document
where and are relative to the J2EE Engine where the Digital Signer was deployed.
h4. IV - SOAP Communication between XI & Government SystemsThe authentication for the communication from XI to the Government Systems is done through the use of digital certificates, as described in the RKT, so no user details are needed.
h2. 4. Further Information
In order to further discusss about NF-e (government requirements) or the SAP NFE solution, the Governance, Risk and Compliance (SAP GRC) can be used. Furthermore, on the short term, a portuguese language forum will be set up and will have a NF-e subforum. I'll update the blog as soon as this forum has been released.
As any SAP product, GRC NFE is under SAP standard maintenance program. Thus, correction notes and new functionalities within Support Packages are being released on a regular basis. So, it is a good practice to regularly monitor SAP Support Portal for new Notes and SAP Software Distribution Center for new Support Packages for GRC NFE. To do so, search for objects in the SLL-NFE and SLL-NFE-JWS Software Components. For Notes, also restrict the search for the SLL-NFE Application Area.
In order to create new customer messages for GRC NFE, use the SLL-NFE component.
+This blog will be regularly updated in order to include the latest changes/enhancements on the GRC NFE product. Make sure to check it regularly for the newest available information. +
- SAP Managed Tags:
87 Comments
