For example, using this multi-sourcing strategy, a computer manufacturing company could stock its materials in different warehouses spread across a region and serve a customer from the nearest located warehouse. If an unforeseen weather catastrophe shuts down a warehouse due to floods, for example, the distributed network model ensures that the company meets customer orders and avoids sales operation shutdowns.

This business model applies to any industry that uses warehouses to fulfill customer orders. I’ll discuss the typical scenarios in which you should consider using the distributed network model. This is not available with your ECC or R/3 system as standard, so I’ll also show you how you can map this model in your ECC or R/3 system using the delivery plant functionality in the material master and the user exit in SAPMV45A (sales order processing program).

When to Use the Distributed Network Model

There are four scenarios in which it’s best to use the distributed network model.

High demand of items from all the regions. When high demand for items is spread across different regions, it makes more sense to meet those demands from a nearby location.

Need to expand warehouse space. This occurs when you have a single warehouse for all customer orders and you cannot carry all the necessary inventory. In this case you should consider setting up a new warehouse in a different customer area to share the inventory and reduce the transportation costs to meet customer orders.

Third-party operated warehouse. When you outsource your warehouse operation to a third-party logistics provider, whose core competency is warehouse management, consider the distributed network model.

Too much dependence on a single warehouse. When you depend on a single warehouse for its operations, you can avoid disrupting warehouse operations by using the distributed network model.

Business Scenario

Let’s take an example of a computer manufacturer in the US that has four warehouses spread across the US:

• East coast: Jackson, New Jersey, 08527 (ECWH)
  
  
• West coast: Seattle, Washington, 98101 (WCWH)
  
  
• South central: Houston, Texas, 77002 (SCWH)
  
  
• North central: Minneapolis, Minnesota, 55414 (NCWH)

In this example, the distributed network model accounts for customer proximity in relation to distribution point for transportation optimization. Based on the historic data, which you generate at a later stage, you can predict the amount of stock that you must keep at a particular warehouse to reduce the inventory carrying cost. When a customer places an order, the system automatically determines the delivering plant closest to the customer. In my example, a one- time customer always has the same customer number. In this case, you cannot assign a particular warehouse in the customer master as the sourcing plant.

Map the Model in Your System

Step 1. Go to the Material Master – Sales Org View. Use transaction MM02. In the Sales Org 1 (view) screen, enter the sales org and distribution channel. After you identify the material that you need to classify as multiple sourced, configure the material master – sales org view as shown in Figure 1.

Figure 1

Leave the Delivering Plant field blank for multiple sourced materials

Leave the Delivering Plant field blank for the materials that you need to identify as multiple sourced. For materials that are single sourced, the system automatically populates the Delivering Plant field with the plant in which the materials should be stored.

Step 2. Define the transportation zone for the region based on the zip codes. For a large country, such as the US, this could be a combination of zip codes. Go to transaction SPRO and follow menu path Logistics Execution>Transportation>Basic Transportation Functions>Routes>Route Determination>Define Transportation Zones (Figure 2).

Figure 2

Example of how to define the transportation zones

You can define the transportation zone in ranges to cover the entire country. For my example, I divided the US into four transportation zones to match the four warehouses I mentioned earlier. Now I can maintain transportation zones by assigning all zip codes between 01000 and 09899 as one transportation zone that falls under the purview of the ECWH warehouse. Similarly, I assign all zip codes from 09900 to 61099 to the NCWH warehouse. This makes it easy to identify the proper transportation zones and the nearest sourcing point.

Step 3. Ensure the warehouse plant definition has a correct zip code. Go to transaction SPRO and follow menu path Enterprise Structure>Definition>Logistics general>Define, copy, delete, check plant>Define Plant. In this screen shown in Figure 3, the ECWH warehouse has the correct 08527 zip code.

Figure 3

The plant zip code 08527 is correct for ECWH

Step 4. Create a new table. In this table, you maintain the relevant order type and relevant sales organization for which you are implementing the distributed network. In my example, I combined two TVARV tables by using transaction STVARV. You can view the entries in the table by going to transaction SE16 and selecting TVARVC.

The first table variable contains the valid sales org for which the distributed network model is applicable. This enables you to implement the multi-sourcing strategy selectively for particular sales organizations. The second table contains the valid document types (Figure 4). This allows you to restrict the implementation to outbound orders or return orders as required.

Figure 4

Valid document types in the TVARVC table

Step 5. Apply user exit in program SAPMV45A. You can find this user exit in program SAPMV45A under include MV45AFZB as shown in Figure 5. You apply this user exit to determine which plant to use for the delivery. You need to add the logic shown in Figure 6 to propose the delivering plant in this user exit include.

Figure 5

Include MV45AFZB form USEREXIT_SOURCE_DETERMINATION

Figure 6

The logic that allows the user exit to determine the delivering plant

How the Distributed Network Process Works

In the standard delivering plant determination, the delivering plant is first picked from the Customer- Material Info Record. Then it moves to the customer master and material master. Finally, it goes to the user exit in SAPMV45A. For my example, in which I require distributed networking, I leave the delivering plant fields blank in the Customer-Material Info Record, customer master, and material master so that the process moves to the user exit as shown in Figure 6.

You can use the Delivering Plant field maintained in the Customer Material Info Record to determine the delivering plant for certain materials, customers, or combinations of materials and customers. This option is useful when your business requirement is to restrict the delivery of certain materials, supplied to a previously identified customer, to come from only one location rather than to follow the distributed network model.

In Figure 6, the initial custom table from Figure 4 determines the order type and sales org combination for which you must carry out the plant determination. You can use this table as a stage in which you can filter the orders that use the multi-source strategy. You could also use the exit routine mentioned near the first decision box to pass over the default delivering plants if required for certain document types.

For example, if you have credit or debit memos in which the delivering plant in the order isn’t important, you would want to propose the default value for the delivering plant. To do this, do not maintain the order type CR and DR in the TVARVC table. Now when you create the order and the system moves to the user exit, the logic fails in the first decision box and exits the routine. This way these orders do not need to go through the full logic of plant determination, which reduces the impact on the system performance.

The scenario is also useful in cases in which you always send returns to a particular warehouse. For example, if the repair department is in ECWH, then all of the return orders created (controlled by document type RE) must have the delivering plant identified as ECWH. For this, you provide a combination of sales org and document type RE to point to a default plant. You can code this in the exit routine statement logic.

Depending on the control required, you can either use an internal table to move the zip code and warehouse plant number, or use a custom table to maintain the sales org, warehouse plant, and zip code, as shown in Figure 6. Using a custom table gives you the option of changing a plant to where a particular transportation zone is mapped in case you don’t expect to ship out any items from the particular warehouse — for example, when you shut down a warehouse due to weather issues.

You can assign the logic for arriving at the nearest zip code and plant in two ways:

• Option 1 uses an internal table to determine the nearest warehouse. The logic for this is shown in Figure 7. The advantage is that this does not impact system performance because you use only internal tables. However, if the business wants to shut down one warehouse or temporarily shut down delivery of all materials from a particular plant, then this option would not work, so you would need to use option 2.

Figure 7

The logic required to determine the nearest warehouse for a zip code

• Option 2 uses a custom table that has different columns in which you maintain sales org, zip code, and the delivering plant. You can restrict the table entries using a zip code range field, for example, from one zip code to another For example, all orders from zip code 85014 that reach the zip code determination logic stage mentioned in Figure 6 will have SCWH as the delivering plant.

To see how this process works, take the example of an order placed in sales org 1000 for material MAT01. The Delivering Plant field in the Customer-Material Info Record, customer master, and material master is left blank. The ship-to party zip code is 85014. When you enter the details in the sales order and press enter, the order goes through the user exit in Figure 5. The sales org and org type are present in the TVARVC table (Figure 4). All of the questions in Figure 6 can be answered “Yes,” so the system determines the delivering plant by using the internal table logic. In this case, the closest warehouse is SCWH.