Large, complex organizations often have multiple IT departments managing separate SAP ERP environments. In turn, each of these IT departments supports a number of business units. The result is a patchwork of IT departments and systems to support various business units. Sometimes these IT departments are intentionally left as separate entities, such as when management wants the flexibility to easily spin off acquired businesses at a later date. Although the IT departments and the systems they manage are often not consolidated within an organization, it is common for commingled business units to want to share resources — such as a warehouse — to increase operational efficiencies and improve offerings to their customer bases. As a result, interfaces between standalone IT systems may be needed to allow the IT systems to support the business processes properly and to allow the company to use the shared resources effectively. Here are some design considerations for setting up the SAP interface for this purpose, which is called Decentralized Warehouse Management (Decentralized WM). I provide specific, necessary settings to ensure that a single warehouse can manage stock owned by two companies running different SAP ERP environments.

High-Level Business Requirements

The following requirements outline the major points that you need to address in the interface design:

• Both SAP environments must continue to use the SAP ERP modules already implemented to support their respective businesses, including materials management (MM), sales and distribution (SD), and SAP ERP Financials
• The fact that warehouse activities are transacted on a different SAP system (WM) should be transparent to the business users transacting on the SAP ERP system; the finance and sales staff should not need to do anything special to accommodate this interface
• The company running WM for the shared warehouse processes all the standard SAP ERP activities (e.g., purchasing, sales, and accounting) for its own business unit. It also processes all the WM activities (e.g., putaway, picking, packing, shipping, and cycle counting) for all the business units that share the warehouse. One warehouse on WM manages the stock for all companies sharing the warehouse. Because of this, operations staff in the warehouse can handle and distribute all products without executing any special steps in the SAP system. Warehouse staff do not need to be concerned with which company owns the stock in their warehouse.

Options

Two solutions to the warehousing problem are available: develop a custom interface in-house or implement Decentralized WM.

Option A – Custom Interface

The first option involves creating a custom interface to send customer deliveries from the SAP ERP system down to WM to be picked, packed, and shipped. WM then sends information about inventory postings back to the SAP ERP system. This keeps both companies in sync from an inventory perspective. This option has drawbacks. Chief among these drawbacks is the expensive ongoing maintenance costs of supporting a custom interface and the large effort required to change the custom programs to adapt to new business requirements. Although these issues are primarily It’s responsibility, other departments within the business are directly affected. For example, as a result of data mapping issues in the interface, customer service could lack a real-time picture of product availability and delivery statuses. This leads to orders missing their shipping dates. Another common casualty of custom WM interfaces is the accounting department: the month-end close is hindered when accounting encounters mismatching stock levels between the two systems.

Option B – DWM

The second option is to use DWM, which constitutes an interface between an SAP's core modules (Materials management, sales and disctribution) and SAP WM. And since the warehouse can run on its own server it has the ability to operate on different versions; whether the core system is ECC or an earlier version it is still acceptable. Information is passed directly via Intermediate Documents (IDocs) and Business Apllication Programming Interfaces (BAPIs). An IDoc is a data container with a predefined structure used to exchange information between SAP systems and the external world. A BAPI is a set of function modules grouped by busniess tasks. Two types of data are exchanged between the systems: master data and transaction data. In a basic implementation of Decentralized WM, master data objects include materials, customers, and vendors. SAP ERP serves as the system of record for these objects, which is the primary location for maintaining most master data objects. Master data is passed to WM using standard Application Link Enabling (ALE) techniques such as change pointers. Depending on the particular needs of your implementation, you can transfer other master data objects — such as batches and classes/characteristics — between systems as well. The distribution of master data objects from the SAP ERP system to WM is illustrated in Figure 1.     The system calls BAPIs as changes are saved in inbound and outbound deliveries and posting changes. In Decentralized WM, you can use transaction BD64 (distribution model) to access these BAPIs. In a basic Decentralized WM implementation, the list of BAPIs to include on the SAP ERP side are:

• InboundDelivery.DeliveryChange
• InboundDelivery.SaveReplica
• OutboundDelivery.DeliveryChange
• OutboundDelivery.SaveReplica

The basic list of BAPIs to include on the WM side are:

• InboundDelivery.ConfirmDecentral
• InboundDelivery.DeliveryChange
• GoodsMovement.CreateFromData
• OutboundDelivery.ConfirmDecentral
• OutboundDelivery.DeliveryChange

These BAPIs trigger their own set of IDocs, which are sent to the partner system. The BAPIs used to transfer transaction data are depicted in Figure 2.    

Solution

Option B, implementing Decentralized WM, is my preferred option. You can implement the Decentralized WM interface quickly: a standard implementation between two SAP ERP systems is performed in about two months. Its flexible interface allows you to tailor it to suit changing business requirements using customizing settings, rather than modify custom development. Decentralized WM requires very little effort to maintain; maintenance steps usually involve troubleshooting IDoc errors related to improper master data settings. In addition, it is fully integrated with other SAP components. This gives users a seamless environment in which to transact their processes.

Implement the DWM Solution

I will now walk through the steps for setting up Decentralized WM in both systems in my example (SAP ERP and WM). This is not intended to be an exhaustive configuration guide, but it touches on all the main components of the implementation.

ALE Settings

The configuration steps for customizing the Decentralized WM interface are straightforward and well documented, so this discussion is limited to settings that are unique to the one warehouse with multiple SAP ERP systems scenario. You can find more information in SAP Help documents “Decentralized Warehouse Management (LE-IDW)” and the “Decentralized Warehouse Management (LE-IDW)” guide. SAP provides functionality to define conversion rules for IDoc fields so that the target system can interpret the data properly. You can mitigate most field mapping by aligning data elements (organizational elements; units of measure; and material, customer, and vendor object definitions) between SAP ERP and WM. SAP mapping tools offer basic functionalities to copy, translate, filter, format, and suppress data from fields in outbound IDoc segments. In addition, you can use custom routines to manipulate data in a more complex fashion. They do not cause any issues when upgrading, but like all custom development, routines should be tested during an upgrade. This is not a modification to standard code, so there is only a small chance that there would ever be an issue. For example, my company upgraded from SAP ERP 5.0 to 6.0 and didn’t need to change any routines. Use the following transactions to set up standard mapping rules:

• Transaction BD62OLD: establishes a list of customer-specific conversion rules. Each rule that you create is assigned to an IDoc segment that exists in one of the message types that you are using to distribute data from one system to the other.
• Transaction BD79: Defines the mapping instructions for all the fields that belong to the segment assigned to the conversion rule. You can assign custom routines to specific fields at this point.
• Transaction BD55OLD: assigns the individual conversion rules to logical systems for each IDoc message type that requires data transformation.

Customizing Settings

A number of configuration settings that control the behavior of the Decentralized WM interface are available in both SAP ERP and SAP WM.

Enterprise and Org Structure

Within the shared warehouse in WM, stock owned by the company operating on SAP ERP is segregated from stock owned by the company operating on WM by each company’s respective organizational elements. The organizational elements plant and storage location serve this purpose. Additionally, using a unique sales area for the SAP ERP business is useful for differentiating customers and deliveries from the rest of the business activity in WM. The design should permit these organizational elements (e.g., plant, storage location, warehouse, sales organization, distribution channel, and shipping points) to match in both the SAP ERP and SAP WMS environments. This simplifies the mapping of IDoc data between the two systems.

Number Ranges

Business objects — such as customers, vendors, materials, and deliveries — are each assigned to a unique range of numbers. Individual records created for each business object are assigned a number that falls within this number range. This allows companies to organize and identify specific data elements in the system. You must consider number ranges carefully when implementing Decentralized WM to connect two systems. Ranges for master data objects such as materials, vendors, and customers that the lea’ system provides cannot overlap with the number ranges the partner system uses. The same holds true for delivery document number ranges. When SAP ERP sends a delivery IDoc to WM, the delivery number must be available or the IDoc fails to post. This means that number ranges assigned to sales orders and deliveries in WM cannot overlap with number ranges for deliveries coming from SAP ERP.

Deliveries

Unless you expect to have shipping notifications from your vendors trigger inbound deliveries, you should define a confirmation control key with the create inbound delivery option. You then need to assign this confirmation control key to all Decentralized WM-relevant purchase order items. You can have the system generate inbound deliveries automatically from purchase orders. The configuration to control this is located in configuration table T163LV, which you can access by following IMG menu path Logistics Execution > Shipping > Deliveries > Define order confirmation for inbound deliveries. A combination of purchase order document type, plant, and storage location determines the confirmation control key to assign to items in purchase orders in which the system needs to create an inbound delivery automatically. When you finish setting up configuration table T163LV, you can trigger inbound deliveries with transaction VL34. An example of an entry in table T163LV that links a purchase order document type/plant/storage location to a confirmation control key is shown in Figure 3.     Two settings in the delivery document configuration are relevant for Decentralized WM: the Delivry Split - WhNo (warehouse number) and the Distrbtn Mode (Distribution mode). These settings are shown in Figure 4, which is accessed with transaction OVLK.     The Delivry split -WhNo check box must be selected in the delivery document type if you want the delivery to apply to the Decentralized WM scenario. The Distrbtn Mode setting controls the timing of when the delivery is distributed to WM. The default setting (Distribution Control by Warehouse Number) is the preferred option because it applies a consistent distribution schedule for all Decentralized WM deliveries going to the same warehouse. Figure 4 shows the settings for a distribution mode assignment to a warehouse.

Decentralized WM Settings

The configuration steps for customizing the Decentralized WM interface are straightforward and well documented, so I will not delve into these details here. You can find information about this in the SAP Help documents mentioned earlier. The key step is to activate the Decentralized WM interface by selecting the External WMS check box in SAP ERP. Follow menu path Logistics Execution > Decentralized WMS Integration > Central Processing > Application> Activate Decentralized WMS to access this setting (Figure 5).     For the system to properly create deliveries for transfer postings and return to vendor/goods receipt reversals, you must define default delivery-related data (i.e., customer, vendor, and sales area) that the SAP ERP system uses when creating deliveries. First, set the default data for transfer postings. Follow menu path Decentralized WMS Integration > Central Processing > Application > Define Interface to Inventory Management and Delivery-Related Data > Delivery-Related Data for Warehouse Number. If possible, assign an external number range to the customer and vendor account groups that you use to represent the sold-to party and vendor. This way you can achieve a consistent customer and vendor identification across all your environments (test, QA, training, and production) and it is not necessary to manually assign unique customer and vendor numbers in each environment. An additional benefit is that you can have a meaningful number assigned to the customer and vendor. For example, you can create a customer called DWM-CST and a vendor called DWM-VND. Then set the default data for return to vendor and goods receipt reversal postings. Follow menu path Purchasing > Purchase order > Set up Stock Transfer Order > Define Shipping Data for Plants. Here it is necessary to create a customer to represent the plant. I recommend you follow the advice provided in the previous step regarding the assignment of an externally assigned number to the customer.

Archiving

An important consideration when you are developing an archiving strategy is the effect that archiving data on one system has on the other system. For example, if you plan to archive a number range assigned to deliveries in SAP ERP and then reset the number range, you must do the same in WM. If you don’t archive and reset the number range on the WM side, then deliveries on the SAP ERP system cannot post in the WM because those delivery numbers are in use. As a result, data is out of sync between the partner systems.

Client Refresh

From time to time it is necessary to refresh different environments in the system landscape — such as the test and training environments — to replace stale data with current, real data from the production environment. Work with your Basis team to coordinate client refreshes of corresponding SAP ERP system and SAP WMS in each of environments. This ensures that material, batch, vendor, customer, delivery, and handling unit data match. In addition, make sure to rebuild the connection between SAP ERP and WM by translating the source clients’ logical systems into the target clients’ logical systems in ALE customizing. The systems cannot exchange data properly until you perform this task.