NOTA FISCAL Implementation
This paper would be helpful for Technical & Functional SAP consultants who want to have basic understanding of Nota Fiscal requirement i.e. fiscal invoices which are issued as per Brazilian law.
Overview of Inbound/outbound interface using Nota Fiscal
According to Brazilian law it is mandatory as of April 1st 2010 to issue fiscal invoices electronically.
Nota fiscal also serves as a financial document, meaning that customers view the nota fiscal as an invoice against which they make payment. They do not request a separate invoice. This procedure is known as “NFe – Nota Fiscal Electrônica” (Electronic Fiscal Invoice). For the electronic reviewing and approving/rejecting of fiscal invoices in real time the government established an organization called SEFAZ. Only upon electronic approval by SEFAZ goods can be shipped to the business partner accompanied by a document stating its govermnemt approval (DANFe).
Two systems are involved to support this new functionality: SAP ECC, providing all required fiscal and supplementary information from the ERP system and another server, which acts as messenger with SEFAZ. Both systems will communicate to each other through XML messages.
Generally SAP standard solution called GRC is used as a messenger between SEFAZ and SAP
To transfer this XML Messages to and fro SEFAZ system an outbound/inbound interface is required.The document aims at overview of this interface along with functional overview Of when this NF Document would be generated.
Below Points Briefs the process Folowed:
1. NF-e must be sent to the government as a digitally-signed XML, with an specific layout. In order to achieve this, an outbound interface module is provided, with the same structure of the XML file.
2. When a new Nota Fiscal is posted, data must be sent to government: the RFC(outbound interface), is called automatically whenever a new billing (through VF01 or VF04), a relevant goods movements in IM that generates a Nota Fiscal is posted on the ERP.
3. Some fields that compose the XML file are not present on the ERP: a BAdI is provided to supply values for these (usually) customer specific data. Data from the XML that have a corresponding value on the ERP are automatically fed to the RFC(outbound interface).
4. The response of the government(approval/Rejection) must be brought back to the ERP via RFC(Inbound interface), where one of these actions must be carried out:
a. If the response is “Authorized”, all went well, and the process can go on.
b. If the response is “Rejected”, there was at least one error with the passed data. In this case, the NF-e must be cancelled (the cancellation XML must be sent to the government), the erroneous data must be corrected (for instance, an incorrect customer information or a required XML field is missing) and, if desired, the whole process will start over again.
c. If the response is “Denied”, that indicates that there are legal issues with one of the parts (either the sender or the receiver), and the product cannot be sold. In this case, the Billing must be cancelled.
5. After the authorization (step 5a), the DANFE (NF-e Auxiliary Document) which is a paper representation must be printed. This will be automatically done by the return RFC.
The R/3 System can create a Nota Fiscal in four different ways:
Integrated into MM Invoice Verification
Integrated into MM Inventory Management
Integrated into SD Billing
Manually with the Nota Fiscal Writer
h3. Introduction to Invoice Verification in MM
Invoice Verification can automatically create a Nota Fiscal. The following graphic shows the relationship between the different MM objects.
for every goods receipt, only one invoice is permitted. The invoice verification transaction automatically creates the Nota Fiscal.
Nota Fiscal Integrated into Invoice Verification
h3. Integrated into MM Inventory Management
- The following graphic shows the relationship between the different MM objects.
h3. Nota Fiscal Integration into SD
The SD process is illustrated below, starting with the creation of a sales order and concluding with the generation of the required nota Fiscal
h4. Nota Fiscal Integration into SD Billing
The system creates a nota fiscal for each billing document that is generated, these being invoices in the above example.
h3. Third Party Scenario
The BR third party case is when we sell to end-customer but send the good to his contractor.
For this scenario we need to have 2 Nota Fiscal, one as a legal invoice for the customer and one to ship the goods.
So the second NF which is created is using the Standard SAP proposal using a Credit flow which does not post.
As we can have only 1 goods movement (PGI) and as a requirement the first Nota Fiscal for the customer must be referenced in the one to ship,
That’s another reason why SAP uses the Credit flow as you create a Credit Memo request with reference.
So the first flow uses Order type ZRCS which acts like a ZSSO with invoice type ZIS
The second one uses Order Type ZRCD (like Credit) and issues a Invoice of Type ZTPS.
h3. Direct Subcontracting Process
The process is similar to a third party scenario, but instead of a vendor, a subcontractor ships the final product to the customer. In this case when we do PGI for a delivery Nota Fiscal is created.
h3. Manually with the Nota Fiscal Writer
The Nota Fiscal Writer (J1b1n Tcode) can be used to enter Notas Fiscal manually. It is possible to enter all relevant Nota Fiscal data.
The Nota Fiscal Writer should only be used if the Nota Fiscal cannot be generated automatically via the integration in MM or SD. It can also be used to display Nota Fiscal created by MM or SD.
Also A reference from the Nota Fiscal to the respective source document can be entered manually.
Nota Fiscal is created with reference as illustrated below:
Create Nota Fiscal with Reference and enter the reference to NF number:
h3. Resending Nota Fiscal:
During Resending also a new NF file is generated.this is done using Tcode
J1BNFE as illustrated below:
In Transaction J1BNFE, select any NF doc number and select Resend from menu bar:
h3. Cancellation of Nota Fiscal:
In some cases i.e if there was at least one error with the passed data to SEFAZ, In this case, the NF-e must be cancelled (the cancellation XML must be sent to the government), the erroneous data must be corrected.
The cancellation is done as follows:
Step1:- In Transaction J1BNFE, select any NF doc number and click on REQUEST CANCELLATION.
After fill up the cancel reason , click on!https://weblogs.sdn.sap.com/weblogs/images/252016716/Nf8.jpg|alt=|src=https://weblogs.sdn.sap.com/weblogs/images/252016716/Nf8.jpg!in Assigned Cancellations Reasons ( the Reason Assigned should be ok!https://weblogs.sdn.sap.com/weblogs/images/252016716/Nf9.jpg|alt=|src=https://weblogs.sdn.sap.com/weblogs/images/252016716/Nf9.jpg!) after click on!https://weblogs.sdn.sap.com/weblogs/images/252016716/Nf10.jpg|alt=|src=https://weblogs.sdn.sap.com/weblogs/images/252016716/Nf10.jpg!and finally click on!https://weblogs.sdn.sap.com/weblogs/images/252016716/Nf11.jpg|alt=|src=https://weblogs.sdn.sap.com/weblogs/images/252016716/Nf11.jpg!
Out Bound Interface Functionality:
To transfer the XML file from SAP ECC to third party server Say GRC, standard SAP functions are being used.
Standard Reports available to do the same are:
J_1BNFEXMLOUT: NFe call to XI
J_1BNFEXMLOUTPARALLEL: XML outbound for parallel phase
Function module J_1B_NF_MAP_TO_XML is accessed within this report
Whose purpose is to Map NF data to XML Structures.
Inside this FM we can implement BADI :CL_NFE_PRINT to make Changes in Standard NFE file created.
i.e as shown Below
Perform CHECK_BADI, checks if this BADI is active.
If it is then we perform desired changes in NFE file throught 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.
Methods FILL_HEADER and FILL_ITEM are used to Modify
Standard NFE fields.
We write the logic to modify standard fields in this method
And then generate XML file
Which is of format as shown below