A corporate group that has multiple companies in different parts of the world must meet export and foreign trade laws, pay local taxes, and follow the regulations of special economic zones. Sometimes meeting those requirements is costly. For example, say the group does not have a manufacturing plant in a country where it must book inter-company sales to abide by local laws. It could procure the goods from another company in the corporate group, store the goods at a local warehouse, and then ship them to the ordering company. This method involves logistics costs, people to do the goods receipt, and investment in setting up a warehouse.

Instead you could set up a virtual plant, which requires use of three company codes. Although standard inter-company procurement in R/3 or SAP ERP Central Component (SAP ECC) involves only two company codes, I have devised a seven-step process to customize inter-company procurement for use in scenarios that require procurement to flow through three company codes. My design uses standard SAP output determination and Business Application Programming Interfaces (BAPIs). You can automate the process so that all related system transactions and postings happen in the background without human intervention. Based on my experience, the implementation should take one to two weeks for development, and two weeks for testing.

Business Scenario

Let me expand on the concept of a virtual plant with an example of a company that wants to meet international business regulations and tax laws. Imagine a computer manufacturer with plants in the US (Company A) and Europe (Companies B and C). In Europe, the manufacturer has a presence in a tax benefit territory (Company B) and also a manufacturing plant in a nearby region (belonging to Company C). Company A procures from Company B, which has a virtual plant.

A virtual plant has all the attributes of a normal plant and is created in the SAP system as you create any other plant. It is called virtual because there is no physical existence of this plant and there are no people operating this plant. (You can also use this process among three actual plants, but in this example, I have made it a virtual plant. Because there are no people in the virtual plant, Company B manages only the orders while Company C handles only manufacturing.) Company A transfers the demand to an actual manufacturing plant belonging to Company C. There is no tax on the sale of goods to Company B by Company C, creating substantial tax benefits to Company B. Figure 1 helps make the scenario clearer.

Figure 1

An illustration of inter-company procurement

In Figure 1, the dashed lines indicate automated movements within an SAP system. A third-party logistics provider (3PL), such as a freight forwarder or logistics company, is not shown in Figure 1 because it is not involved in my example. Although I will go into each step in more detail, take a look at the steps and see how they relate to each other.

1. Create a stock transport order (STO)
2. Validate the purchase order (PO) #2
3. Create an outbound delivery
4. Create the outbound delivery from the virtual plant
5. Complete the invoice verification
6. Bill the company
7. Receive the goods

If you have a 3PL to ship the goods, the shipment paperwork can be printed on the 3PL printer directly from the outbound delivery at Company B. This delivery has a reference of actual delivery created at Company C. This helps the 3PL choose the correct delivery and allows the GR to happen against the virtual plant delivery at Company A, Plant 0600 (Figure 1). If you don’t have a 3PL, it means that you are doing the shipping function by yourself, which is unlikely. If that’s the case, the shipment documents are printed on your own printer. This does not affect the design or the concept in any way.

Look at the STO creation at Company A and call it PO #1. When the PO is created, it automatically creates an output message (pre-configured by your functional analyst) with a special function to be proposed for this PO creation. You can configure the output using transaction NACE and select a relevant application area, such as an output for purchasing (e.g., EF) as shown in Figure 2.

Figure 2

Output configuration for PO

Figure 2 depicts the output ZZUG configuration. You can also see the main program (ZMM_I_MME083) for processing all message outputs and the FORM routine for individual output (SUB_PO #2).

Now that you have a good overview, I will go into the steps in further detail.

Create Inter-Company Stock Procurement

Step 1. Create an STO. Company A creates the STO as Plant 0600 to procure from Company B’s Plant 3921.The output ZZUG creates another STO to procure from Plant 3930. This output uses a special function and uses a BAPI, in this case BAPI_PO_CREATE1. While passing the input values to the BAPI, also pass the delivery address from STO #1. For referencing, store the value of PO #1 in the communication reference field of PO #2. In Figure 3, the output message of PO #1 at company code A, plant 0600 is 0006082887 while PO #2 created 6082008.

Figure 3

Output messages of PO #1 and PO #2

Step 2. Validate the PO #2. The STO at Company B now exists to procure from Company C’s Plant 3930. It also has the reference of the original PO #1 (Figure 4). In this case, I have populated Your Reference with 0006082007. The automatic creation of PO #2 avoids running any sort of MRP at the virtual plant. Referencing the documents makes it easier for reporting capabilities.

Figure 4

PO #2 at company code B, plant 3921 procuring from 3930 plant

Before delving into further steps, you first need to configure the message outputs needed for the subsequent steps. I am taking the approach of showing the configuration and its use in the process simultaneously.

Configure the message outputs to trigger goods receipt at the virtual plant and to trigger the outbound delivery from the virtual plant. You can configure the outputs by using transaction NACE and to select a relevant application area, such as ME (inventory management) in this case (Figures 5 and 6).

Figure 5

Output configuration for triggering goods receipt and outbound delivery at the virtual plant

Figure 6

Details of message output along with main program and FORM routine SUB_GI

Step 3. Create an outbound delivery. You can do this from Plant 3930 (Company C) using transaction VL10B (delivery #2). Prepare the picking and post goods issue (PGI) for delivery #2. Delivery #2 is 80001384, which is not shown here but is in the PO #2 purchase history details that you’ll see later in this article. After the material document is created by delivery #2, the system triggers an Output ZZGI (for a GR). When triggered, the Output ZZGI calls on BAPI_GOODSMVT_CREATE to create a GR in the virtual plant against outbound delivery #2. Figure 7 shows the material document created from the goods issue of delivery #2.

Figure 7

Material document from PGI of delivery #2

If you click the Details from Item button and go to output details, you see a processing log (Figure 8). This log tells you that the PGI action has automatically created Material Document 4900010761.

Figure 8

Output message at the material document of delivery #2 showing Material Document 4900010761

Now I will show you how to validate that the material document created above is indeed a GR in the virtual plant (Figure 9).

Figure 9

GR document at virtual plant (check movement is 101and plant is 3921)

The use of this process for the GR is also helpful when you work with STOs involving serial numbers, as shown in Figure 10. The standard SAP system does not allow a one-step procedure for the STOs that involve serial numbers, but using this design you can work with the serial numbers as well. Refer to the serial number details on the GR document (Figure 10).

Figure 10

Material document created for GR at Plant 3921 with serial numbers

Step 4. Create the outbound delivery from the virtual plant. At this stage, you have set up the GR in virtual plant 3921. Now you need to create the outbound delivery from the virtual plant. This happens automatically based on the message output determination you have already configured. The material document created by the GR (4900010761) at the virtual plant has another output, ZZGR, which is used to trigger a delivery. When triggered, ZZGR calls upon BAPI_OUTB_DELIVERY_CREATE_STO to create an outbound delivery for the PO #1 created in step 1. Figure 11 shows the output processing details of the GR material document and log details.

Figure 11

Output message of the GR material document shows delivery 80001386 has been created

The delivery document created (80001386) has a reference to the first delivery created in step 3. This referencing lets the three plants know the link between deliveries so that the appropriate delivery notes can be bundled together and sent along with the shipment. This link happens based on user need via the form routine (Figure 12).

Figure 12

Cross-referencing deliveries allows for more visibility and reporting capabilities

Note that there should not be any picking at the virtual plant. The item category used for this delivery has been modified to be irrelevant for picking by removing the check mark from the Relevant for picking box (Figure 13). Un-checking this is important because there is no one physically available to do the picking of goods at this virtual plant. The SAP job (WS_MONITOR_OUTB_DEL_GDSI) for picking runs in the background during the PGI posting for this delivery.

Figure 13

Virtual plant enabled for non-picking relevance

Step 5. Complete the invoice verification. Once the logistics are complete (i.e., PGI is done at plant 3930), it can run the billing due list and bill inter-company customer 3921. The user configures the LIV Output RD04 to trigger the invoice to company code B. The configuration of RD04 is beyond the scope of this article.

Step 6. Bill the company. In this step, the virtual plant (belonging to Company B) bills Company A. This is similar to step 5 and mentioned here for the purpose of overall process completion. Steps 5 and 6 do not affect the core functionality explained in this article.

Step 7. Receive the goods. At this stage the goods have arrived at Plant 0600 and are ready to be received and placed into stock. Use transaction MIGO to receive the goods in the SAP system against outbound delivery 80001386.

At this point, all the steps are complete and the PO histories for both PO #1 and PO #2 are updated (Figures 14 and 15).

Figure 14

PO #1 showing updated history

Figure 15

PO #2 showing updated history