All cross-border exports require documents that declare the goods to the government authorities and provide details of the shipment. Shipments leaving United States borders, for example, require a commercial invoice and a shipper export declaration, among others.

On receipt of the goods, the import declaration and relevant duties apply. At the point of entry, a customs official requires the importer to present the relevant documents describing the goods and indicating that all entry requirements have been met. In the case of any discrepancy — for example, the shipped quantity might be less or more than stated, or the part is not the one listed in the trade declaration document — these documents need to be resubmitted to the authority with the corrections. Figure 1 illustrates this process.

Figure 1

Process for correcting and resubmitting trade documents

Correcting this documentation might be a legal requirement governed by most countries. If you cannot provide corrected documentation, your company risks fines and loss of export privileges in its country. The importing country might similarly impose fines and revoke import privileges, and it may seize the shipped material.

The documents supporting the export shipments are generated through the output condition technique in SAP R/3, and they may be submitted in hard copy or electronic form. To reflect corrections in these documents, you need to change the transaction from which these documents are generated. If the transaction is referenced from a preceding document, there might be limitations in carrying out all the corrections — for example, if you increase the line item by more than what the reference document shows for the shipment or change the material number for wrong part shipment.

The output conditions are attached to the proforma document, which could be created against a sales order (billing type F5), delivery (billing type F8), or as part of the customer invoice without using the proforma document (billing type F2). Generation of billing documents and output conditions is configured and set up in the Sales and Distribution (SD) module.

Carrying out these corrections outside R/3 is a manual, labor-intensive task, and the changes are not tracked and recorded in the system. Also, it might be extremely difficult to archive all the document corrections for audit purposes for the periods of time typically specified by governments.

R/3 can keep track of the changes and get the values from the previous transaction, document, or table (for price, material characteristics, classification data, license details, and so on). Setting up SD to make changes to trade documents requires a little configuration in most cases. Adding a line item or changing a part number in a line item requires an SAP enhancement.

I will show you how to correct these documents and track the changes in SAP R/3. First, let’s review how export documents are generated.

Generating an Export Document

You can generate the export documents in different ways based on the business process defined by your company. I will use the most recommended technique to demonstrate the correction process. The steps in R/3 for the flow are:

Order (shipping entity) > delivery >goods issue (post goods issue) >billing document (proforma) >print trade documents >goods receipt (receiving entity).

The trade documents are determined as part of the output type generation in the proforma document, which has all transactional values. Figure 2 shows the output types generated in a proforma document (transaction VF03, billing type F8). These output types have an associated program that determines the necessary data to print in the trade document forms. (For example, it could be a SAPscript program.)

Figure 2

Output types generated on a proforma document display

You can view the output types while you are in the Display Output of VF03 via menu path Header>Output. The Medium field captures the method used for transmission (printout, EDI, etc.). The Partner function (ship to or bill to) is the key field used in determining the output. The next two fields are Language to indicate which language to use for printing, Change to indicate if the message has been changed, and Processing mode (automatically after saving the document or manually through the print command). You can also see the details by using the options in the top buttons for Communication method, Processing log, and Further data.

Use transaction V/40 (Figure 3) to see the configuration for the Output type assignments to Program and Form. The configuration for output types is assigned based on application (V3 indicates billing). The Medium options (Print output, EDI) have associated program, FORM routine, and Form (SAPscript for printouts).

Figure 3

Program and form output type assignments for a trade document

You can view or print these trade documents through transaction VF03 (billing document display) or VE72 (Foreign Trade document print) using the proforma number and the relevant output types. Figure 4 shows a sample trade document, a commercial invoice.

Figure 4

An example of a comercial invoice document

Fixing Quantity Discrepancies

The business requirement might be to correct and resubmit only the trade document in question — the commercial invoice in my example — independent of inventory and financial system corrections. You therefore correct the trade document based on the output type in the proforma document, because the original tradedocument captured the values from the original proforma document and printed it on the forms.

To make corrections in SD to the originally submitted trade document, you might want to refer to the original proforma document and have a provision to edit it in the system. Make the necessary changes and save to create the new, corrected proforma document. This corrected document then generates a corrected trade document through the output type determination.

The program associated with these output types that captures the required data needs to be coded in ABAP/4. You can modify the same program that prints the original invoice to print the corrected trade document. If there is an intermediate document (sales document type, custom credit memo request) before the proforma document, then the program must generate output types for corrected trade documents. The associated forms (SAPscripts) also need to be changed to reflect the corrections in the printout. Figure 5 shows the corrected commercial invoice.

Figure 5

Corrected commercial invoice

To change a quantity in the original document, you could use an intermediate document, which acts as an editor. In other words, you could copy the proforma document to another document. My example uses a credit memo request order type. The purpose is not to issue any credit, but rather to use the request order as an editor. You do so by executing transaction VA01 (sales order create) and entering the intermediate sales document type for editing purposes. Make the necessary changes to the quantity referenced from the original. With this new intermediate document, you can go to the billing document’s create transaction VF01 and create a new corrected proforma. In the document field of VF01, enter the intermediate sales document created (credit memo request), relevant billing type (in this example, it is F8 for proforma), and save the changes. This creates the corrected proforma document.

The system tracks these changes, and you can view them through the standard document flow and change history functionality of R/3. Figure 6 displays the document flow with the original proforma, intermediate document (Credit memo request), and the corrected proforma documents. Use transaction VF03 if you have proforma and VA03 if you have the intermediate document credit memo request and view the document history through the menu option Environment>Document flow. The corrected proforma documents also capture changes that occur as a result of the correction — pricing, for example.

Figure 6

Document flow with multiple corrected proformas

Coding the program for retrieving and printing forms may be specific to the company, and in the next section I show how you can capture discrepancies in a document. For example, the corrected trade form might show the original proforma details (number, reference document, material, and so on) and the corrections by striking through the originals and printing the corrections next to them.

The above process solves quantity-shipped discrepancies, but the standard copy control configuration setting doesn’t allow you to change the material numbers for wrong part shipments. Changing the material number while creating a corrected proforma creates two proforma numbers (a split-billing document), one showing the original material number and the other with the correction. This might be a problem when printing trade documents with corrections. For example, making a lot of corrections generates multiple proforma documents. Figure 7 illustrates the split-billing problem.

Figure 7

Split-billing problem

In Figure 7 you can see two line items with net values. The first line item is the proforma with corrected line item and the second is the item before correction. When you save the corrected document, it creates two proformas (splitting in two) — one with the correction and one without it. Another problem is that the corrected proforma number (in which you changed the material number) loses the link to the original document.

The User Exit

To solve this problem, you might have to implement ABAP/4 code via a user exit in a standard R/3 function module. To implement the solution, follow these steps:

1. Create an intermediate document by copying (in this example) a standard credit memo request, using transaction VA01. You might want to make changes to the configuration based on your requirement. As a process step, copy the original proforma document to the intermediate document. Set up the credit memo request (sales document type) and copy it with reference to the billing document. I explain the relevant configuration steps later. Figure 8 below shows the proforma document being copied to the intermediate document.
2. Once you have copied the proforma document to a credit memo request (sales document type), you can edit the line item details (quantity or part number). After you make the necessary changes, save the document and note the document number. Figure 9 below displays the intermediate editing document (transaction VA01). In Figure 9, a new line has been added. (This could be one of the business cases, where an extra part number is received at the destination.)
3. Use the above document to create a new proforma document. Go to Create billing document (transaction VF01), enter the document number and billing type (F8 for proforma), and press enter. This takes you to the Proforma Create screen. Review the details and click on the save icon.
   
   
4. This new proforma document (billing type) has the new output types for the trade documents generated. If you made the necessary changes to the background program to pick up the corrections and print in the form, you can use the billing document display (transaction VF03) to print these corrected trade documents. Execute VF03 (or menu path Logistics>Sales and Distribution> Billing>Billing Document Display) and enter the proforma number. Go to Billing Document>Issue Output to Printer. In the pop-up (Figure 10), enter the relevant output type and press enter or click on the green checkmark. Another pop-up window appears for entering the logical destination (printer) and number of messages (copies). After updating this information, click on Execute to trigger the printout.
   
   
5. As the intermediate document is open after the creation of the proforma document, you might want to go to the change document (transaction VA02) and apply a rejection code to close the document for any further processing. Figure 11 shows where to apply the rejection code.

Figure 8

Copy the proforma document to an intermediate document (sales document type) through transaction VA01

Figure 9

Intermediate document editor (sales order document type)

Figure 10

Enter the output type in the pop-up to set up printing for the trade document

Figure 11

Document display with rejection code

Configuration Steps

SD requires the following configuration steps to activate the corrected trade document functionality:

1. Define an order type (say, ZINT) by using transaction VOV8. You can create this new order type copied from a standard order type (credit memo request). In the order type definition (go to the details in VOV8), select the Reference Mandatory option in the General Control section. As this order type is created with reference to a proforma document, select the option M in the Reference Mandatory section. This allows the document to be created with reference to the billing document.
   
   
2. Assign the above order type to the appropriate sales area through transaction OVAZ.
   
   
3. You can also use an existing item category. I recommend that you create a new item category (say, ZINI). You can do this through the menu path SPRO>Sales and Distribution> Sales>Sales Documents>Define Item Categories.
   
   
4. Assign the item category (ZINI) to the order type created (ZINT) through transaction VOV4.
   
   
5. Create a new incompletion procedure (say, ZC) for the above item category through transaction OVA2.
   
   
6. Assign the new incompletion procedure (ZC) to item category ZINI through transaction VUP2. If you prefer, you can create a new incompletion procedure for the header and assign it to order type ZINT.
   
   
7. Maintain copying control from billing type (F8, proforma) to sales (ZINT) order type through transaction VTAF.
   
   
8. Maintain copying control from sales document type (ZINT) to billing type (F8) through transaction VTFA.

Technical Changes

To allow the addition of line items (new material) or a part number change in the existing line item, you need to apply the following ABAP/4 code using these steps:

1. Create a project through transaction CMOD.
   
   
2. Name the enhancement.
   
   
3. To the function module EXIT_SAPMV45A_003, apply the following code through a Z-include. This is the function module that is called for a copy requirement on the header level, which is where the original proforma is copied to the intermediate document (in this example, credit memo request).

if xvbak-auart = 'ZINT'.
  data : w_vgpos like xvbap-vgpos.                  
  clear : xvbfa.                           
  loop at xvbap.                           
   if not xvbap-vgbel is initial and xvbap-updkz eq 'D'.      
    w_vgpos = xvbap-posnr.
   endif.
   if xvbap-vgbel is initial and xvbap-updkz eq 'I'.
    xvbap-vgbel = xvbak-vgbel.
    xvbap-vgpos = w_vgpos.
   
    xvbfa-mandt = sy-mandt.
    xvbfa-vbelv = xvbak-vgbel.
    xvbfa-posnv = xvbap-posnr.
    xvbfa-vbeln = xvbap-vbeln.
    xvbfa-posnn = xvbap-posnr.
    xvbfa-vbtyp_n = xvbak-vbtyp.
    xvbfa-rfmng = xvbap-zmeng.
    xvbfa-meins = xvbap-zieme.
    xvbfa-rfwrt = xvbap-netwr.
    xvbfa-waers = xvbap-waerk.
    xvbfa-vbtyp_v = xvbak-vgtyp.
    xvbfa-erdat  = sy-datum.
    xvbfa-erzet = sy-uzeit.
    xvbfa-updkz = 'I'.

    modify xvbap.
    append xvbfa.
   endif.
  endloop.
 endif.

Rajen Iyer

Rajen Iyer is the cofounder and CTO at Krypt, Inc. Rajen has written several in-depth, best practice articles, white papers, patents, and best-selling books on SAP Logistics and SAP Global Trade Services, including Effective SAP SD and Implementing SAP BusinessObjects Global Trade Services. He is also an invited speaker at industry conferences.

You may contact the author at Rajen@kryptinc.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.