In business scenarios it is very common to see one time customers. Similarly, we also have a one time ship to party in a business. This is very useful, particularly when your customer (C1, C2....Cn) do not want to hold the inventory and thus reducing his cost and shipping time. So whenever the customer receives a purchase order from his customer (referred to as end customer in this blog like EC1, EC2.....ECn), he would then place a purchase order with your company. However we cannot store any master data for the ship to party in this case since your customer may ask you to ship the goods to any of his customers. The reason we do not maintain any master data is, your customer in turn may be dealing with plenty of end customers and we are not sure who they are till the time of order creation. And that's why we have the concept DROP SHIP. Apart from this we don't have any direct dealing with the end customer apart from delivering stocks to him.
The context of this Blog has been built based on the business process from North America. Also there is a contractual agreement between the supplier company and its customers that the drop shipment will be applicable only to specific counties of US during a year. The contracts can be renewed by the customers every year to include new counties. But at any given time two customers cannot serve the same county. This avoids any conflict in the business contracts issued. So when an order comes from a customer he may ship to only those counties which are agreed in the contract like Kent, Baltimore, Carroll, Charles etc. So the customers who want to engage in a drop ship business get contracts yearly and know which areas they are going to serve.
The below picture shows the supplier company which has implemented SAP and maintains master data for customers C1, C2.... Cn. We create a dummy ship to party with partner function 0002 Ship to Party and assign it to each of these customers.
Supplier Company (SC) - for which SAP is implemented as per this scenario.
Customer (C1, C2...Cn) - Customers of Supplier Company SC.
End Customer (EC1, EC2...ECn) - Direct customers C1, C2...Cn.
End Customers for Supplier Company.
We can infact compare this scenario to a 3rd party order processing where we ask our vendor to send the goods directly to the customer instead of us receiving the stocks.
The key to the success for this process is to be able to
- a) Calculate taxes based on the ship to party location.
To do this we need to setup an RFC connection with an external 3rd party tax system since this is predominantly used in NA to pull the latest taxes.
- b) Control drop shipments to specified counties as agreed in the yearly contract.
We have setup a custom table which maintains the customer number in the allowed counties. During sales order creation a user exit is used to check this Z table whether entered ship to party is in the permitted county or not.
- c) Print the changed ship to address at the order level in delivery documents and not ship to master data.
To do this we can check the VBPA-ADRDA field as it captures whether ship to party address is being entered at the order level. Then we can go to ADRC table to fetch the address entered at the order level by linking VBPA-ADRNR to ADRC-ADDRNUMBER.
- d) Ensure the Drop Ship address is entered at the order level as we don't have master data (or can only have dummy data) for this.
We can have a custom message / pop up to tell the user to input the ship to address.
