Both SAP R/3 and Advanced Planning and Optimization (APO) allow a company to allocate product across distribution chains based on predetermined criteria, ensuring a planned distribution. Product allocations can be based on any number of market dynamics represented by SAP characteristics. These characteristics enable a more efficient analysis of a market and provide an organization opportunities to use market share analysis, new product distribution strategies, or sales forecasts to map to its product allocation strategies.

Characteristics in SAP are used as criteria according to which data can be summarized. A planning hierarchy comprises a number of characteristics mapping to key segmentations in your company's markets. For effective planning and reporting purposes, it is essential that these planning hierarchies represent how your product "goes to market." This enables more efficient use of your time and resources when building and maintaining a plan. It is also important that the structures or tables used to store this data maintain the correct relational consistency when this data is aggregated or disaggregated.

By integrating R/3 with APO's Demand Planning (DP) and Global Available to Promise (GATP), you can add flexibility to the R/3 product allocation tool. This enhanced capability allows you to adapt product allocation to the marketing hierarchies in your organization. I will demonstrate how to do this and explain the various options you have to integrate product allocation in R/3 and APO.

You have several alternatives to introduce product allocation into your R/3 and APO system landscape, and my goal here is to help you understand them. In addition, developers responsible for creating customized Logistics Information System (LIS) structures and update rules will find information on creating the necessary formula to ensure that your data is updated on a consistent basis, if you decide to use R/3 planning for your product allocation solution.

For example, R/3 uses info structure S140 to map a planning hierarchy that includes useful characteristics (sales organization, distribution channel, customer group, and sold-to party). However, S140 seldom represents an effective planning hierarchy, and it is important to use a structure that maps the characteristics that define your market. I will show that organizations using APO have greater flexibility in designing characteristic combinations that match the distribution and marketing structures than those found in most organizations. However, it is also possible to use R/3 information structures to map the organizational units in your company. You will see that the LIS structures in R/3 Logistics Controlling Flexible Planning map to the product allocation group in APO GATP and the InfoCube in APO DP.

Product allocation procedures are an integral component of the business processes used in SAP SCM, including forecast to stock, replenishment to procurement, and order to cash. Introducing a product allocation strategy into these processes enables a focused view on the control and allocation of products across distribution chains, especially in situations where demand exceeds supply. Product allocation is a useful tool to enforce new product distribution strategies or to ensure that available inventory is first allocated to strategic customers. It is often used to share a high-volume product on a equitable basis amongst an eager sales force. Product allocation strategies have found acceptance in consumer product organizations and in many make-to-stock or capable-to-promise environments where high-volume items, high-value items, or products with long manufacturing lead times need to be distributed on a consistent basis.

APO's DP and Supply Network Planning (SNP) modules enable organizations to adopt sophisticated forecasting and planning methodologies. This allows them to build more accurate forecasts that contain more detailed information and can be adapted and modified in shorter planning lead times. Organizations planning a move to incorporating APO product allocation strategies into their system landscape have a number of alternatives to consider. I describe them below, first for using product allocation in R/3 and then for using it in APO DP.

Product Allocation in R/3

R/3 product allocation configuration uses the Sales and Distribution (SD), Production Planning (PP), Material Management (MM), and LIS modules. You activate it by setting configuration and master data options in each R/3 module. Product allocation uses Flexible Planning in Sales and Operations Planning (SOP). Organizations that have not yet migrated their planning systems to APO commonly use SOP. SOP is composed of two elements: standard SOP and Flexible Planning. Standard SOP is predefined for the standard package and Flexible Planning offers several options for user-specific settings. The Flexible Planning menus can be accessed either through SOP or through Logistics Controlling. These paths can be used interchangeably.

The LIS module is used to create the data communication structures and update rules necessary to store transactional data. Sales orders created in SD with an item that has a product allocation object assigned to it use product allocation available-to-promise (ATP) rules to access data in the LIS tables when creating, changing, or saving a document. Sales orders use product allocation ATP rules to allocate available quantities against the plan. Material that has a product allocation object assigned to it in the material master is checked by the product allocation ATP rule in the sales order, and the order quantity is checked against allocations in the LIS tables. Flexible Planning in SOP is used to maintain the data stored in LIS tables such as S140.

The trigger that causes the ATP product allocation check to occur on a sales order is found on the material master (Basic view) in the field Product allocation determination procedure (Figure 1). If this field is populated and the product allocation ATP configuration has been completed, then the Product allocation field is used to identify the product allocation determination procedure in Flexible Planning.

Figure 1

The Product allocation field identifies the product allocation determination procedure in Flexible Planning

Flexible Planning is based on information structure S140. However, you can create a customized information structure Sxxx that has the same functionality as S140, but is specific to your organizational units. Likewise, you use Flexible Planning to create a user-defined planning table for planning the product allocation data. This is known as a "planning type." The standard planning type for table S140 is COMMIT. However, you can create any number of planning types for each LIS structure you create. With each planning type, you may add macros used to calculate differences in key figures. In my example, I will use macros to identify the open product allocation quantities by subtracting planned product allocation quantity from consumed product allocation.

Option 1. Pre-APO R/3 landscape: The traditional product allocation approach has been to maintain everything in R/3. Figure 2 shows the traditional approach to product allocation. After all necessary development has been completed — LIS tables activated, SD configuration, Flexible Planning planning types, and planning macros — and the material master is updated, then the following process is available.

Figure 2

The shaded upper left portion represents option 1, product allocation in R/3. The entire figure represents option 2, begin the migration from R/3 to APO. (click on image for large version)

A sales order is processed with a material that has a product allocation planning determination procedure assigned to it. As Figure 2 shows, the order quantity is compared to available product allocation quantities through the ATP mechanism. If the available quantity exists for the characteristic combinations defined on the sales order, then these quantities are automatically confirmed against the planning object in Flexible Planning after you save the document. The available quantities for the customer/material (characteristic combinations) are then reduced in the planning table.

Option 2. Begin the migration from R/3 to APO: In this landscape, you continue to use R/3's product allocation functionality, but you begin to migrate your planning and forecasting tools to APO. In this scenario, R/3 and APO operate as independent systems. However, it is possible to use the APO master data transfer utility and R/3's Core Interface (CIF) module for master data transactional data updates. This enables the synchronized planning of data sets in both systems. The primary advantage of this option is that it allows phasing in of APO DP and GATP functionality without disturbing existing operations.

The following describes how synchronized planning works: Flexible Planning is used in R/3 to update the data in the planning hierarchy defined by the LIS information structure. This data can now be transferred to the product allocation group in APO GATP and then used to update APO DP where it can be manipulated and then validated against a forecast model. As in option 1, the R/3 sales order quantities are confirmed against product allocation tables in R/3. The plan is created and maintained in the Flexible Planning module and then transferred on a regular basis to APO.

If you continue to plan product allocations using SOP Flexible Planning in R/3 and product allocation in SAP APO, use an info structure for planning product allocations in SAP R/3, and use the product allocation group for checking product allocation quantities in SAP APO. The planning data for the info structures must then be transferred periodically to the product allocation group via the CIF. Actual sales data and the product allocation quantities are confirmed in R/3 and synchronized on a regular basis with the APO product allocation plan. In this example, product allocation quantities are replicated in both systems and can be planned in both systems.

You continue to use LIS info structures for creating and maintaining the product allocation plan in R/3. You map the R/3 LIS info structures to an APO product allocation group, which is used to maintain product allocation quantities in APO. Characteristic value combinations in APO represent the planning hierarchy. Planning data from the R/3 info structure (Flexible Planning) maps to the product allocation groups and can be transferred periodically to the product allocation group via the CIF module (Figure 2).

To use this option, follow the R/3 menu path Logistics>Central Functions>Supply Chain Planning Interface>Core Interface Advanced Planner and Optimizer> Environment>Data Transfer>QTSA Product Allocation Quantity.

Option 3. Integrated APO and R/3, APO-maintained: Sales orders are entered in R/3 and the ATP check is carried out in APO. The product allocation plan is created and maintained in Flexible Planning (option 4) or APO (option 3). Both options enable you to create sales orders in R/3 and then use APO to carry out the product allocation check for materials that have a product allocation determination procedure assigned to them in the material master.

In this option, sales orders entered in R/3 can be processed and confirmed directly in GATP using data in APO DP. This is the most integrated product allocation landscape linking R/3 order processing with APO's product allocation and DP tools. R/3 is the order processing system, and APO confirms available product allocation quantities. APO is the tool used to maintain the product allocation plan.

In this scenario, you use GATP to confirm and control the allocations against every sales order. The interaction between R/3 and APO enables the product allocation plan to be built in APO as well as enabling the product allocation check to be made in APO. The confirmation of order quantities at the schedule line are automatically passed from APO into R/3. SAP classifies this as Product Allocation with direct checking of the planning area. This relates to the supply chain integration model as well as the transactions used. Direct check of the planning area requires that you check Planning Area Indicator in the product allocation group. The product allocations are thereby read directly from the planning area. The same area is used for planning. Changes to the incoming orders quantity and the product allocation quantity are visible immediately.

The advantage of direct online access to the data in the planning area is that changes in both the product allocation plan and the check against product allocations are immediately visible. A change in one is reflected in the other. The two major disadvantages in option 3 are that this process has a negative effect on system performance. Also, product allocation checking and planning cannot be carried out simultaneously, since the product allocation time series and planning are stored together. This results in the planning process and sales order allocation process blocking each other and each activity must be scheduled separately (Figure 3).

Figure 3

Option 3, integrated APO and R/3, APO-maintained

Option 4. Integrated APO and R/3, use Flexible Planning in R/3: A solution that overcomes some of the disadvantages of option 3 is to use Product Allocation without direct checking of the planning area. Building and maintaining the product allocation plan can be carried out in APO using DP. The advantage of this method is that the checks against product allocations and planning are made independently of each other and therefore do not affect each other's operation.

In this scenario, you create sales orders in R/3. A check against product allocations is then carried out in APO for the items on the sales document. Planning of the product allocations can be carried out in R/3 using Flexible Planning or directly in APO DP. Independent of planning, the check against product allocations uses the information in the product allocation group. This means that the check against product allocations and planning take place separately from each other (Figure 4).

Figure 4

Option 4, integrated APO and R/3 with Flexible Planning in R/3 (click on image for large version)

As outlined in options 3 and 4, planning can be carried out directly in APO or remain in R/3. ATP checking in options 3 and 4 is done directly in APO. Once you decide that you would like to replace SOP planning and Flexible Planning functionality with APO's facilities, it is necessary to move your planning data into APO DP. As discussed earlier, planning in APO is carried out in APO DP and data is transferred to the planning area, which is used by DP.

Changes in DP are not updated automatically in the product allocation group. In addition, the incoming order quantities from the product allocation group are also not transferred automatically to the planning area. Using reports, you can copy the incoming order quantity data into the planning area to compare actual data there with planning and then adjust the planning. You then copy the changed planning data into the product allocation group.

Customizing an R/3 Structure

As mentioned earlier, info structure S140 has a preset list of characteristics that don't often map to a dynamic marketing environment. Multiple sales, marketing, and distribution hierarchies are needed to segment different markets, and you often must add characteristics.

To successfully use product allocation in R/3 or APO, it is important to build a planning hierarchy that incorporates at least the primary characteristics used to distinguish your organization's actual marketing hierarchy. If this is achieved, it is easier to map customer demand to the product allocation plan.

Building structures with the correct update rules should not present many problems for experienced LIS developers. The issue is how to replicate S140's aggregation and disaggregation functionality in a new structure. I will focus on how to build a customized R/3 LIS structure that maps S140's functionality and specifically product allocation. If you continue to plan product allocations using Flexible Planning in R/3, then you can proceed as follows when building a customized LIS structure for product allocation.

The customized solution was used in a consumer products company and is based on LIS structure S140. However, to resolve a problem, it was necessary to define a customized structure, which I'll name S842, that defines the characteristic Sold To at a planning level lower than the material in the planning hierarchy. The intention of customized LIS structure S842 is to control Sold To at a lower level than the material to ensure that the available quantity is easily identifiable and set before defining the limit by customer sold-to ID. This structure allows you to create a plan that is specific about the allocation of material to important customers. The structure uses the customer sold-to ID, which defines the quantity assigned to each sold-to customer. The balance of remaining unallocated material quantities are then split among customers outside the target segment using the wild card value "#." Figure 5 shows the characteristics and key figures for LIS structure S842.

Figure 5

Customized LIS structure S842’s characteristics and key figures

Figure 6 outlines the update rules for information structure S842. When creating the update rules for S842, the following formula must be used to ensure that when moving from one hierarchy to the next, the aggregation and disaggregation of data needs is consistent in each planning level. Consistency means that using any characteristic, the aggregated sum is correct at any level in the hierarchy. To invoke this functionality in the S842 structure, use the formula examples provided by S140 to create new formula for each characteristic in the new customized structure.

Figure 6

Customized LIS structure S842 updates rules

Note that the formula values 641, 642, 640, and 644 need to be defined and activated prior to including them in S842 update rules.You will find that 641 is a copy of 141, 642 a copy of 142, and 644 a copy of 144. However, the new versions were modified to fit the planning hierarchy in S842. You need to be familiar with the differences between a formula_value_object (characteristic definition) and a formula_value (key figure) and use these formulas appropriately in the LIS structure that you create.

The following describes how you define the formula value objects shown in Figure 6 for customized LIS structures:

Product allocation obj., formula 140 (FORM MCV2_140): Use this formula unchanged. It defines the product allocation determination procedure as well as the product allocation object.

Sales organization (VKORG), formula 641 (FORM MCV2_641): Create the formula 641 by replicating formula 141. Then modify the formula by first setting the info structure to S842E (SELECT COUNT). Next, set FORMULA_VALUE_OBJECT = MCVBAK-VKORG. Finally, check that the select count variables represent the same format as the LIS structure, the lowest variable being VKORG.

Distribution channel (VTWEG), formula 642 (FORM MCV2_642): Create formula 642 by replicating formula 142. Modify the formula as shown in Figure 7 by first setting info structure to S842E (SELECT COUNT). Then set FORMULA_VALUE_OBJECT = MCVBAK-VTWEG. Finally, check that the select count variables represents the same format as the LIS structure, the lowest variable being VTWEG.

FORM MCV2_642.
* Investigation of the Distribution Channel if it 
is a member of the planning hierarchy.

  DATA: REPLACE(2),
* Prior characteristic adaption
        HLP_VKORG LIKE MCVBAK-VKORG.

  IMPORT T190H-KOMAS FROM MEMORY ID ‘MASKE’.
  WRITE T190H-KOMAS TO REPLACE+1(1).
  TRANSLATE HLP_VKORG USING REPLACE
  IF MCVBAK-VKORG = HLP_VKORG.
*  remain under this branch until another is 
available. 
    MCVBAK-VTWEG = SPACE.
    TRANSLATE MCVBAK-VTWEG USING REPLACE.
    FORMULA_VALUE_OBJECT = MCVBAK-VTWEG. 
    EXIT.
  ENDIF.

  SELECT COUNT(*) FROM S842E    “ - - modify - -”
                  WHERE KONOB = MCVBAP-KOSCH 
                    AND VKORG = MCVBAK-VKORG 
                    AND VTWEG = MCVBAK-VTWEG.
  IF SY-DBCNT > 0.
*   it is a member —> O.K.
    FORMULA_VALUE_OBJECT = MCVBAK-VTWEG.
    RETURNCODE = 0.
  ELSE.

    MCVBAK-VTWEG = SPACE.
    TRANSLATE MCVBAK-VTWEG USING REPLACE.
    FORMULA_VALUE_OBJECT = MCVBAK-VTWEG.
  ENDIF.

ENDFORM.

*———————————————————————————————————————————————————-*

Material (MATNR), formula 640 (FORM MCV2_640): Create formula 640 by replicating formula 140. Modify the formula as shown in Figure 8 by first setting info structure to S842E (SELECT COUNT). Set FORMULA_VALUE_OBJECT= MCVBAK-MATNR. Finally, check that the select count variables represent the same format as the LIS structure, the lowest variable being MATNR.

FORM MCV2_640.
  DATA: REPLACE(2),
        HLP_VTWEG LIKE MCVBAK-VTWEG.

  IMPORT T190H-KOMAS FROM MEMORY ID ‘MASKE’.
  WRITE T190H-KOMAS TO REPLACE+1(1).
  TRANSLATE HLP_VTWEG USING REPLACE.
  IF MCVBAK-VTWEG = HLP_VTWEG.
*under remaining branch until 
    MCVBAP-MATNR = SPACE.
    TRANSLATE MCVBAP-MATNR USING REPLACE.
    FORMULA_VALUE_OBJECT = MCVBAP-MATNR.
    EXIT.
  ENDIF.

  SELECT COUNT(*) FROM  S842E   “- - modify - -  
                  WHERE KONOB = MCVBAP-KOSCH
                    AND VKORG = MCVBAK-VKORG
                    AND VTWEG = MCVBAK-VTWEG
                    AND MATNR = MCVBAP-MATNR.
  IF SY-DBCNT > 0.

*   it is a member —> O.K.
    FORMULA_VALUE_OBJECT = MCVBAP-MATNR.
    RETURNCODE = 0.
  ELSE.
*   If customer favors masking 
    MCVBAP-MATNR = SPACE.
    TRANSLATE MCVBAP-MATNR USING REPLACE.
    FORMULA_VALUE_OBJECT = MCVBAP-MATNR.
  ENDIF.

ENDFORM.

*———————————————————————————————————————————————————-*

Sold-to party (KUNNR), formula 644 (FORM MCV2_644): Create formula 644 by replicating formula 144. Modify the formula as shown in Figure 9 by setting the info structure to S842E (SELECT COUNT). Set FORMULA_VALUE_OBJECT = MCVBAK-KUNNR. Finally, check that the select count variables represents the same format as the LIS structure, the lowest variable being KUNNR.

FORM MCV2_644.
* Investigation of the material if it is part of the planning hierarchy
  DATA: REPLACE(2),
        HLP_MATNR LIKE MCVBAP-MATNR.

  IMPORT T190H-KOMAS FROM MEMORY ID ‘MASKE’.
  WRITE T190H-KOMAS TO REPLACE+1(1).
  TRANSLATE HLP_MATNR USING REPLACE.
  IF MCVBAP-MATNR = HLP_MATNR.

*   Under a remaining branch, only a remaining sign can stand again
    MCVBAK-KUNNR = SPACE.
    TRANSLATE MCVBAK-KUNNR USING REPLACE.
    FORMULA_VALUE_OBJECT = MCVBAK-KUNNR.
    EXIT.
  ENDIF.

  SELECT COUNT(*) FROM S842E  — modify —
                  WHERE KONOB = MCVBAP-KOSCH
                    AND VKORG = MCVBAK-VKORG
                    AND VTWEG = MCVBAK-VTWEG
                    AND MATNR = MCVBAP-MATNR
                    AND KUNNR = MCVBAK-KUNNR.
  IF SY-DBCNT > 0.
*   it is a member —> O.K.
    FORMULA_VALUE_OBJECT = MCVBAK-KUNNR.
    RETURNCODE = 0.
  ELSE.
*   Setze Kunden auf Maskierungskennzeichen
    MCVBAK-KUNNR = SPACE.
    TRANSLATE MCVBAK-KUNNR USING REPLACE.
    FORMULA_VALUE_OBJECT = MCVBAK-KUNNR.
  ENDIF.

ENDFORM.

*———————————————————————————————————————————————————-*

Key figure, formula value 146, Incoming orders qty. (FORM MCV2_146): Set a formula value (Fmla) 146 for the key figure Incoming orders qty. (Figure 10). This is the standard SAP object and does not need to be modified.

Figure 10 Set the formula value for Incoming orders qty. to 146