Recently there was the need to customize this scenario in the company I work for, and I did not find any article or post related to customizing VFRB, especially related to Localization Brazil.
This document was put together for a VFRB scenario customization for Brazil Localization, with Nota Fiscal Eletrônica (NF-e)
Process
Retroactive Billing is required when there is a retroactive price change.
For example: Let’s suppose several invoices were billed with material ABC for the price of $ 100.00. The Sales Department then negotiates with client a retroactive price increase for the past recent months, so the price has to be retroactively changed to $ 120.00. Now the difference of $ 20 for each material ABC has to be invoiced.
This requirement is easily fulfilled and customized if there are very few invoices to be re-billed. There is the option of doing one by one, using VA01 referencing a billing document, and then VF01.
In this specific scenario, there are so many previous invoices that this needs to be done massively.
VFRB
This transaction is the transaction used to Retro-Bill massively. It will first reevaluate all documents fitting the selection and show the difference amount. Then if needed, it will perform the retroactive billing to square any differences.
The VFRB has within it a configuration screen that is displayed automatically the first time that the transaction is used.
The two fields above are for Credit Note, and the lower ones for Debit Note. In this example we will only use and customize the Debit Note scenario.
Fields on the left to ask for a type of billing document, which must be of type Debit Note. Invoices will be generated with this document type. The fields on the right are the Reasons for Credit or Debit Note. In this case we will use reason 200, which is "Price difference: too low".
The first step before the user runs VFRB, is to change the price condition in VK12 retroactively, for the specific date that the price was changed.
When VFRB is executed, according to the selection criteria used, it will compare the value of the invoices in the selected period versus the new value that would be calculated using the new price, and will show us the differences.
In this example, VFRB was executed for only one material. The ZB01 are the normal sales documents, invoiced on 01.03.2013, and ZB10 (in the two first lines) are debit notes already generated for their corresponding ZB01.
In the first two cases, as the Debit Notes have already been generated, the difference value shows as “0,00” in the field where SAP would show the difference amount to be billed.
In the other lines where no ZB10 document has been generated, we can see the amount that has been billed, the quantity, the value that has to be billed, and also the old and new prices.
After selecting the checkboxes next to each invoice, the system allows the user to either simulate or generate the Retroactive Billing. SAP will generate one invoice for each invoice already issued. The reason for that is that the VBRK header has a field that indicates to which NF-e this new invoice refers, thus it is not possible to generate one retroactive billing document for many previous invoices.
However, if the report is run with multiple materials and an NF-e was issued with various materials, a Debit Note will be created for that NF –e, with all selected materials included.
An interesting aspect of using VFRB is that the SAP will put with Debit Note in the document flow after it is generated. The example below is the document flow of the first billing document from the list in the previous image.
Customizing
The ideal in this case is to have the individual Debit Note scenario via VA01/VF01 already configured in the system.
In this case, the individual scenario was customized first so that it could be used also for VFRB.
My main sales document in this example is the ZB01, with which invoices were issued with the original prices before the retroactive change.
The ZB10 is the document for Debit Note
Below are the steps I checked / customized
1) Define Sales Document Types
Sales Document, the so called "dummy sales order" in the SAP documentation. This is how the billing document will know what kind of NF-e to use. So it must be created and the customizing should be correct.
2) Define Item Categories
Sales Document Item which already existed from the individual Debit Note scenario
3) Assign Nota Fiscal Type to Sales Document Types
4) Define Billing Types
5) Maintain Sales Document Item Category
The ZB10 -> ZB10 link already existed for the manual scenario, and in this step the ZB10 -> ZB01 link was created, since when we execute the Retroactive Billing in VFRB, the system creates a ZB10 billing document with ZB01 items
6) Maintain Copying Control For Billing Documents
Copying control: Billing document to billing document (VTFF)
7) Maintain Billing Document Item Category
Mark billing document ZB10 with item ZB01 as relevant to invoicing
😎 Maintain Billing Types
9) NF-e Type for Retrobilling must be 2N, so that the <finNfe> tag in the XML is automatically set as "2"
10) Define And Assign Pricing Procedures
In the pricing for the Retroactive Billing, the PDIF condition must be present. This condition will have the difference value between the invoice with the old price and the final calculated new price. I used the same pricing iNa pricing da Nota Complementar, deve existir a condição PDIF para que a diferença entre as duas faturas seja calculada e lançada. Eu utilizei a mesma pricing from ZB01 in ZB10, all I did was add PDIF condition below the main price condition (in this case, ZB00).
Tax
1) Added the code below to program ZNFE_PRINT_DANFE, to include legal text in DANFE printout.
Did not do it via customizing (messages options in the Invoicing -> Brazil Localization) because since we copy data from an Invoice Document and not from a Sales Order, this information is not there. Would only exist if this process was being done via VA01, where we'd have to fill in the Reference field with the original NF-e number, which is then transported to the invoicing document.
2) Another detail was that I included the PO number in the <xPed> tag of the NF-e's XML , because since VFRB references another billing document and not the Sales Order, the invoice document does not have the PO number. This change was done in FILL_ITEM of the routine that fills the XML structure, and has to be sought out in the original Sales Order.
Conclusion
Obviously each SAP has different scenarios with their own peculiarities, but for a basic sales scenario with NF-e, this is the required configuration.
I have also had experience with a sales scenario where there was Industrialization, ie, the client sends the parts to be used in the assembly of the final product, and the final product is sold with the CFOP 5124/AA, with a labor percentage calculated and included in the invoice.
To make VFRB work for this scenario was much more difficult, since VFRB calculated wrong values because of the difference generated by the percentage of labor. In this case I needed to create other conditions and also had to include some formulas.
I hope that the above document is useful and helps others who also have trouble customizing this scenario.
- SAP Managed Tags:
3 Comments
