R/3 acts as the system of record and the main system for product life cycle management, supply chain processes, coordination with other partners, and collation of all financial data. SAP for Retail coordinates one of the distribution channels for your company and helps manage your global retail chain of stores. I’m going to discuss some of the retail business processes and focus on the integration points between R/3 and SAP for Retail. I will not go into great detail on integration with functionalities such as Point of Sale (POS) or Internet Transaction Server (ITS) software.

SAP for Retail uses its own set of terms and related transaction codes. Table 1 shows a few major differences in terms and how they map to R/3. To go to the retail-specific menu, use transaction code W10T in SAP for Retail.

Organization Structure

As I mentioned, R/3 is the system of record in the implementation. SAP for Retail transactions, at the end of the process, must move to R/3. To enable this, the organization structure for the R/3 retail instance is set up along similar lines to the R/3 instance. In the example in Figure 1, the US has one plant 5001 under company code 0050 and purchasing organization 5001 in R/3. Therefore, all retail stores in the US also have one company code 0050 and purchasing organization 5001 in SAP for Retail.

Figure 1

Typical organizational structure for SAP for Retail

Material Fetch Process

To enable communication between R/3 and SAP for Retail in the same company, the material numbers in R/3 and the article numbers in SAP for Retail have to be the same for the same physical materials. SAP for Retail uses ALE to transfer and distribute data. This technique is the same for all SAP applications and is used in SAP for Retail to distribute different kinds of master data and transaction data via defined interfaces known as IDocs. A standard ALE infrastructure is assumed.

The first step is to define the port for R/3 (or for any other system with which you are integrating). Do this via transaction WE21 (ports) in IDoc processing. WEDI is the transaction code for the ALE/EDI workbench. Your functional consultant, Basis team, or EDI expert can perform this step.

The next step is to get the material master data (contained in transaction MM03) from R/3 for any material that also needs to be sold in the retail stores. The material data in SAP for Retail has to be similar to the data in R/3, as the procurement for the materials is handled from R/3 (Figure 2).

Figure 2

Document flow between SAP for Retail and SAP R/3 to create an article master in retail similar to the material master in R/3

In this case you initiate a request for the material in SAP for Retail. Use the standard SAP IDoc MATFET (material fetch) from the SAP for Retail instance to send the request for the material details from R/3. The MATFET IDoc in Figure 3 has the material number details only.

Figure 3

MATFET IDoc requesting material from R/3

The SAP standard function module IDOC_INPUT_MATFET processes the MATFET IDoc. This results in the R/3 modules (Materials Management [MM], Sales and Distribution [SD], or Financials [FI], for example) picking up all the details for the material number (contained in MM03) and compiling them in an IDoc called MATMAS (material master data). MATMAS is sent automatically from R/3 to SAP for Retail based on the ALE port configurations and Partner Profile set-ups (WE20). MATMAS has the relevant fields with data similar to the corresponding fields in the material master in R/3 (Figure 4). If you look closely at the various segments in the IDoc, you’ll see that each segment represents data from various master data tables (e.g., MARA [general master data], MAKT [material master description], MBEW [accounting data], and MARC [production/MRP data]).

Figure 4

MATMAS IDoc with relevant material master data

Standard function module IDOC_INPUT_ MATMAS01 processes MATMAS IDocs in SAP for Retail. You use this function module to create a material master. You can also change the function module slightly to map the fields in MATMAS to ARTMAS IDocs. Function module IDOC_INPUT_ARTMAS processes ARTMAS IDocs and creates the article master.

Procurement Process

The logistics processes with the vendors are mapped out in R/3. In my example I procure all material from R/3. It is possible to replicate the logistics processes on SAP for Retail as well. However, this implies extra data maintenance effort on two instances. In my example, R/3 also manages all the other channels of distribution, such as resellers and Web stores, so it makes sense to have the logistics set up only on the R/3 instance. SAP for Retail acts as a customer to R/3, and the purchase orders (POs) on SAP for Retail move to R/3 as sales orders. Figure 5 shows the procurement process.

Figure 5

Linkages between SAP for Retail and R/3 click here to view a larger version of this image

You can use several standard SAP functionalities, such as merchandise assortment planning or forecasting (with or without seasonality) with replenishment run in MM or Materials Requirements Planning (MRP) runs in Production Planning (PP) to determine requirements and create purchase orders in SAP for Retail per the retail stores’ requirements. You send these requirements (purchase orders) to R/3 as sales orders. It is an interesting challenge for the integration of the two SAP instances. Next I will discuss the messages used to exchange information between R/3 and SAP for Retail and the set-up for this process.

Configure the retail stores as customers in R/3. In this scenario, map the stores to only one customer. Several ship-to parties are linked to the customer, with each ship-to party representing a different store (Figure 6). This enables the vendor to send an 850 EDI IDoc to MM manually to have the goods shipped directly to the store from the vendor location based on the ship-to party information.

Figure 6

Partner functions screen of customer master showing individual retail stores mapped as separate ship-to parties click here to view a larger version of this image

The POs in SAP for Retail create the output message NEU (message type ORDERS). Standard function module IDOC_OUTPUT_ORDERS processes the POs. This message is processed by the standard program and sent across to vendor number P9999. P9999 is a dummy vendor for the plant 5001. The R/3 system recognizes the IDoc as coming from the SAP for Retail system. It processes the IDoc into a sales order by the inbound process code ORDE (functional module IDOC_INPUT_ORDERS) for inbound message type ORDERS, as shown in Figure 7.

Figure 7

Process POs with inbound message type ORDERS click here to view a larger version of this image

The rest of the flow is as explained in Figure 5. You can follow the standard procurement process for SAP for Retail requirements in R/3. The vendor/OEM or plant gets the requirement from the sales order created in SAP. Once the physical goods are ready, they are shipped directly to the retail store based on the ship-to address. The delivery in R/3 creates a Advanced Shipping Notification (ASN) in SAP for Retail. When the store receives the product it posts a goods receipt (via ITS) for the purchase order created in SAP for Retail. That completes the procurement of goods at the retail store (both physically and in the SAP for Retail system). The billing and invoicing are proxy transactions that are adjusted in R/3, which is the financial system of record.

Data Synchronization and Flow Between Systems

One critical aspect of the integration of the systems is to have the changes in R/3 reflected in SAP for Retail. The system provides standard IDoc types for exchange of information on all types of master data (e.g., info records, material master changes).

You need to send all sales data to the R/3 system and record it. The financial consolidation between systems in the particular scenario I am discussing happens by custom interfaces. All sales data in the various stores is stored in Info Structures in SAP for Retail. The Retail Information Structure (RIS) used for this purpose is S120. This data is sent over to R/3 in a custom-built interface. Relevant debit and credit entries are transferred into the R/3 system. This is an automatic process based on a daily background job for the interface that collects the data and sends it across to R/3. In R/3, a job is triggered when the file with the data comes in, and it processes the debit or credit entries.

Additional Integration Hints

Middleware. Sales data flows from POS software at the retail front end to SAP for Retail via non-SAP middleware. The middleware is custom built, but SAP provides easy integration with use of BAPIs and related configuration settings in SAP for Retail. You complete the relevant configuration for POS with transaction SPRO and menu path Sales and Distribution>POS Interface. Note that a flow of article data and prices goes from SAP for Retail to POS as well.

Internet Transaction Server (ITS). ITS supports the Web interface you can use to access SAP for Retail instances by stores globally. The stores log into R/3 via the Internet and post transactions. ITS can manage all retail store activities such as goods receipt, transfer of goods between storage locations, and posting physical inventory documents. You configure the ITS transactions that determine the relevant movement types and product catalogs in the IMG. You can also use SAP NetWeaver Portal in place of ITS if you have the functionality.

Trilokesh Satpathy

Trilokesh Satpathy, PMP, is a consultant with Infosys Technologies Limited with more than six years of SAP consulting experience spanning automobile and computer manufacturing companies. He holds a bachelor’s degree in mechanical engineering and a post-graduate degree in business management.

You may contact the author at editor@scmexpertonline.com.

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