Anyone who works for a company that trades and distributes goods is likely to know about the drop-shipment process. SAP R/3's Sales and Distribution (SD) module offers a standard answer to the drop-shipment requirement called "third-party order processing," but it has a few shortcomings. For example, you can't use it to send a material safety data sheet (MSDS) to customers who require one, and it doesn't accommodate traders who must have the exact value of traded goods on their books at all times.

R/3's third-party order processing functionality is useful in many situations, and I will tell you where you can use it as is. For other situations, I will explain its shortfalls and introduce you to ways to overcome them. Both the standard third-party order scenario and the alternative that I discuss here are available for all R/3 releases from 3.1H to 4.7.

The definition of a drop-shipment is when a company (the trader) takes a sales order from its customer for a product that it does not carry in inventory. The company issues a purchase order (PO) to a specific vendor — it could be the manufacturer or a distributor of the ordered product — and the vendor ships the product directly to the end customer (Figure 1).

Figure 1

(1) Customer places an order with the trader. (2) Trader places a PO with the vendor. (3a) Vendor delivers products to customer. (3b) Vendor invoices trader for the delivered quantity. (4) Trader invoices customer for delivered quantity.

This process is widely used for traded goods. A number of my clients use it, for example, when they import goods from overseas. Instead of physically receiving the goods into their warehouse, however, they instruct the manufacturer to directly (drop) ship to the customer. This streamlines and shortens the process and avoids unnecessary transportation, warehousing, and handling costs.

As with everything, there is a trade-off. This process has logistical, legal, and accounting ramifications such as knowing exactly when ownership changes from the manufacturer to the trader and then to the end customer, or knowing the exact quantity that was shipped and when it arrived. All of these aspects need to be dealt with. For example, the ownership question is important for legal and insurance purposes. It is also important to know the exact time/date and the quantity that arrived at the customer's dock so that the billing process can be both accurate and expedited.

The key here is the linkage between the sales and purchasing processes — i.e., a linkage between a sales order item and PO item. R/3's standard process is sophisticated and meets most of the common requirements (Figure 2). The sales order automatically initiates a PO by creating a purchase requisition. You can use all of the standard capabilities or R/3's purchasing components here — e.g., the purchase requisition can follow a release strategy and either automatically or manually turn into a PO.

Figure 2

(1) A sales order creates a purchase requisition. (2) A purchase requisition is converted into a PO. (3a) A vendor invoice is entered against the PO. (3b) The vendor invoice releases adjusted sales order quantities for billing. (4) A customer invoice is created, referencing the sales order and reflecting vendor invoice quantity.

Relevant information is instantly exchanged between the sales order and PO; the material, quantity, desired delivery date, and ship-to address (the address of the customer) are passed along from the sales order to the purchase requisition/order. The PO processes all appropriate scheduling activities taking into account any available lead times, and it calculates a delivery date, which is then passed back to the sales order. Through the link between the two documents, any relevant changes (e.g., to quantity or delivery date) to the PO are replicated in the sales order.

This process, as sophisticated as it is, fails to fulfill critical requirements like these:

• The end customer expects an MSDS sent to them. This document is most often generated through the delivery process. SAP's third-party order process skips this step, so a separate process is needed to work around this shortcoming. The same could apply to advanced shipping notices (ASNs) and a number of other shipping documents that are usually generated at the time of delivery in a standard sales process.
• The trader trades at high volumes or in expensive goods and requires having the exact value on its books at any given time. This could be for insurance purposes or to simply account for all inventories that are owned by the company at any given time. To achieve this, a receipt of values — i.e., taking ownership of the goods — at some point during the process (depending on the shipping terms, also called Inco terms) is required. Subsequently, the inventory (value) needs to be reduced once the end customer receives the goods. This requires a goods issue process.

Other situations might benefit from having extra steps available. In all of these cases, R/3 users would have to use the standard sales process without the benefits of the third-party process. In other words, they would need to create a standard sales process without the link to the purchasing process.

I have come across similar requirements over and over again. To meet them, I have applied a solution I worked out six years ago under R/3 3.1. It requires customization that is usually not done (creating and adjusting schedule line categories and account assignment groups), but the end result is exactly what the customers need: a sales process that allows processing goods receipts and goods issues into and out of a phantom warehouse (Figure 3). At the same time, it allows the usage of drop-shipment features (the link between the sales order and the PO). This process seems a bit more complicated than the standard process. However, it allows for drop shipments to be processed in the same way as regular sales orders — i.e., a variation of the standard process rather than a new process.

Figure 3

(1) A sales order creates a purchase requisition. (2a) The purchase requisition is converted into a PO. (2b) A delivery is created, referencing the sales order. (3a) A vendor invoice is entered against the PO. (3b) A goods issue is performed for the delivered quantity. (4) A customer invoice is created, referencing the sales order and reflecting vendor invoice quantity.

To create this process, you first need to understand the configuration of the standard third-party process.

The central SD Customizing object that controls/initiates the third-party order process is the schedule line category (Sched.line cat.), located under Sales Order Item. The most commonly used schedule line category is CP (Figure 4). The settings of this category determine whether this order item is relevant for delivery and define the appropriate movement type for post goods issue.

Figure 4

The settings for the CP schedule line category determine an order’s relevancy for delivery and define the movement type for post goods issue

The standard schedule line category that controls the standard third-party order process, CS, however, is defined in a way that no delivery is required (Figure 5). In addition, it defines the document type for the purchasing document to be created as well as a specific account assignment category (Acct.assig.cat.) to be used in the purchasing document. The CS schedule line category also has a special incompletion procedure (Incompl.proced.). Account assignment group X is assigned to the schedule line category CS (Figure 6). Note that it defines that no Goods receipt is expected for the purchasing document, as goods are directly received by the end customer.

Figure 5

Schedule line category CS controls the third-party order process

Figure 6

Acct assignment cat. X defines that no Goods receipt is expected for the purchasing document

By tweaking a few of these settings, you can combine the features of a third-party item with those of a standard-delivered item. To do so, I recommend you first create a special Sales Order Item Category in SD Customizing. You can then manually select this item category to initiate a third-party order, or you can determine it automatically via the Item Category Group defined in the material master. Whether you create a new sales document type is up to you. Use your discretion to make that decision based on all other aspects (reporting issues, orders combining standard-delivered and drop-shipped items, and so on).

Then define a new schedule line category ZS (Figure 7) in SD Customizing and assign it to the previously created sales order item category. You define the delivery relevance (Item rel.f.dlv.), the goods issue (Movement Type), and the appropriate purchasing document (Order type and Acct.assig.cat.). As you can see, I have also assigned a special Acct assignment cat. Y (Figure 8), which requires a goods receipt for the purchased items (remember, you are going to perform a goods receipt transaction in the system even though you never physically receive the goods).

Figure 7

Define a new schedule line category ZS

Figure 8

Assign special Acct assignment cat. Y

Let's review: You have a logistics process that requires usage of SAP's third-party order process. For more accurate inventory accountability or other requirements, however, you want to add a step to simulate the receipt of goods into inventory and issue the same out of the inventory. By creating a custom sales order item category, a schedule line category, and an account assignment category with appropriate settings, you combined the features of the third-party order process with those of an SAP standard order process.

Ali Sarraf

Ali Sarraf is the managing partner at Enowa Consulting. He has 15 years of experience as a senior consultant for SAP Business Suite applications and 20 years of IT experience. During much of his career, he has focused on helping customers optimize their logistics business processes by analyzing and explaining cause-and-effect relationships and by bringing the machine and the human sides of IT closer together.

You may contact the author at ali.sarraf@enowa.com.

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