>>PREVIOUS>>

WHAT IS ALE?

Sample ALE scenarios

Now let’s explore a couple of sample ALE scenarios. The first illustrates a few interfaces with an external warehouse management system using ALE technology. The second depicts the distribution of master data between two or more R/3 systems. These scenarios are a small sample of the multitude of possible ALE interfaces.

Example 1: Consider a business scenario in which R/3 needs to be interfaced with an external warehouse management system (WMS) (see Figure 3). This scenario assumes that the Inventory Management module is being implemented. In an outbound interface, the SAP application communicates to the WMS picking requests — Materials in the warehouse that need to be picked for packing and shipping. Message type PICKSD, whose corresponding IDOC type is SDPIOD01, is used. This IDOC consists of a header with fields for delivery number, shipping point, total weight of delivery, units of measurement, and the name and address of the ship-to party. The header is followed by one or more detail segments that contain the delivery items with fields for item number, Material number, quantity, and units of measure.

Figure 3 Sample ALE scenario-Interface with Warehouse Management System.

After the receipt of the picking request and completion of the operation, the WMS sends a pick confirmation back to SAP. This is an inbound interface to SAP from the external system where message type SDPICK is used. Its corresponding IDOC type is SDPIID01. This IDOC type also has a header segment followed by one or more detail segments. The IDOC communicates the Material quantities picked by the warehouse based on deliveries sent earlier. It can handle batch splits, movement type splits, and also invoke a “post goods issue” process.

As seen in Figure 3, there are several inbound inventory interfaces that can be handled by one single message type WMMBXY. These inbound interfaces are typically goods movement transactions, including inventory receipts (with or without a purchase order), inventory status change, goods receipts against production orders, and inventory reconciliation. Most goods movement types are supported by this message type. The corresponding IDOC type is WMMBID01 (or WMMBID02 in 4.x releases), which can handle multiple line items for a single header. In the case of inventory reconciliation, ALE function modules need to be enhanced to modify the data contained in the inbound IDOC for inventory adjustments based on comparing the stock in WMS versus SAP. This can be achieved easily with a few lines of code in a Customer function (user exit) provided by SAP in the ALE function module.

Example 2: Let’s look at another simple ALE scenario distributing master data across multiple R/3 systems (see Figure 4, page 86). In large companies, there are advantages to distributing applications and databases, especially if the differentiating parameters can be used to segment the data discretely, such as plants, lines of business, geographic locations, and departments. In this example, the company headquarters is responsible for maintaining master data such as Customer Master and Material Master. This is loosely coupled with two different plants/companies, 1001/US01 and 2001/EU01, to which master data is distributed. ALE provides the capability to filter data and distribute it only to relevant systems. We can distribute the master data pertaining to that particular plant/company code. The filter object type used for message type MATMAS (Material Master) is WERKS (plant), and for DEBMAS (Customer Master), it is BUKRS (company code). Initially, after the Customer Master and Material Master are loaded during conversion at the headquarters, we can transmit the relevant data to each plant or company. Then, on an ongoing basis, we can capture the changes occurring to the master data at headquarters and communicate them to the corresponding plant/company.

Figure 4 Sample ALE scenario-distributing master data.

R/3-to-R/3 InterfaceS

Now let’s talk about how to build interfaces between two or more R/3 systems. While the underlying concepts are almost the same for either R/3-to-R/3 or R/3-to-external system interfaces, there are important differences in configurations and in the mode of communications. We will work with an example of distributing characteristics and classes from one R/3 instance to another. While using objects such as Materials, Customers, and Vendors, it is often necessary to classify these objects to further describe their nature and to distinguish them from other objects. In SAP, we use characteristics and classes to classify objects. Characteristics are attributes that further describe an object. For example, a chemical’s temperature sensitivity and a customer’s store shelf square-footage are characteristics of objects that can be maintained in the R/3 classification system. Classes are groups of characteristics that conform to a class type — such as Material or Vendor. While the term classification data refers to the actual values of the characteristics, classes and characteristics can be considered configuration data. In SAP, it is not possible to transport class and characteristic data using the Correction and Transport System (CTS) across systems (such as development, QA, or production). ALE provides message types, IDOC types, and function modules to distribute class, characteristic, and classification data to other systems. Let’s walk through the process of building an interface to distribute characteristics and classes from one R/3 instance to another.

The message types available for this purpose are:

CHRMAS — Characteristics master
CLSMAS — Class master
CLFMAS — Classification data.

>>>NEXT>>>