When integrated with R/3 or a mySAP ERP environment (from Advanced Planning and Optimization [APO] 3.0 onwards), the Allocation Planning function in Demand Planning (DP) acts directly when sales orders are created or changed, and when the GATP function is performed for the allocated products. The confirmations in the sales orders are based on what the allocations are for the criteria that you preset in Allocation Planning. In this article, I’ll show you how the Allocation Planning tool is integrated with the GATP function.

Link the Allocation Planning to GATP

Let’s walk through some of the configuration settings required for GATP to use Allocation Planning. I’ll start by looking at the master planning object structure defined for Allocation Planning in my example. Clearly it should include all the characteristics that sales orders use when you perform an allocation check. An allocation plan is made using the characteristics with which you want to restrict the allocation. For it to be effective, a sales order should use the same characteristics. My example is a simple scenario in which the allocation plan is created by product, plant (distribution center), and customer. The planning object structure in APO therefore contains the product (9AMTNR), distribution center from which the product is shipped (9ALOCNO), and the customer (A_CUSTOM), shown in Figure 1.

Figure 1

Review planning object structure

The Planning Area in Figure 2 has the following key figures:

• Allocation Plan (ALLOQTY): Allocation plan for the product, plant, and customer
  
  
• Consumed Allocation (A_ALLOCNS): As the customer order is confirmed, the confirmed quantity shows up as consumed allocation in the APO Planning area. Only the balance (allocation plan minus consumed) is available now for a new order in that bucket for that customer.
  
  
• Forecast (A_FCLCETD): Forecast for the product, customer, and plant from which the product is sourced to the customer
  
  
• Total Supply (A_NETSUPP): All incoming supply including stock (as a result of constrained planning)

Figure 2

Planning area key figures

Now you can proceed with the configuration settings required in APO to make GATP work in conjunction with Allocation Planning.

Step 1. Define the field catalog. Since the product allocation group can only be defined with the characteristics in the Field Catalog, the Field Catalog should include all the characteristics that the system uses in the product allocation groups you define. The APO Field Catalog includes all of the characteristics that the Product Allocation group uses. The Product Allocation group is a set of characteristics, key figures, and a time bucket profile (which you will see later). These characteristics and key figures have values that come from the sales order or are updated in the sales order once the system does the GATP check.

In APO, use transaction SPRO and follow menu path Advanced Planning and Optimization>Global Available to Promise>Product Allocations>Maintain Field Catalog. When you click on the Condition field shown in Figure 3, a list of applicable fields appears. You can select the relevant fields for the Field Catalog. In my example, I selected the following fields for the product allocation group:

• KONOB: product allocation object

• MATNR: product

• WERKS: plant

• KUNNR: sold-to party, which maps to the customer in a later step

Figure 3

Define the Field Catalog

Step 2. Create the product allocation object. Use transaction SPRO and follow menu path Advanced Planning and Optimization>Global Available to Promise>Product Allocations>Maintain Product Allocation Object. The system saves product allocations by product allocation object for each characteristics combination in the product allocation group. Define the Object name and the object description in the screen shown in Figure 4. In the next step, you define the product allocation group.

Figure 4

Define the Product Allocations Object

Step 3. Create the product allocation group. Use transaction SPRO and follow menu path Advanced Planning and Optimization>Global Available to Promise>Product Allocations>Maintain Product Allocation Group. Give a name to the product allocation group (ALLOBJ in my example). I selected the Check planning area check box, shown in Figure 5. That means that when the system performs an availability check on the order, it checks the allocation planning area for available allocations.

Figure 5

Define the Product Allocation Group

In the Check Date area, I entered MCVBEP in the Comm. Structure field. That means the availability check is performed for each schedule line in the sales order. The Check Date (MBDAT) corresponds to the material availability date in the order. Time bkts prfl means that you define and check the product allocation quantities in the weekly time buckets. When an order causes an availability check, the system uses the material availability date to determine the correct time period to look for allocations in the allocation planning area.

Click on Characteristics to select the characteristics from the field catalog required for the product allocation check. The product allocation object (KONOB as shown in Figure 6) shows up by default as a required characteristic. Select the other characteristics determined to be relevant from the allocation perspective. The available choices are the fields you selected in the Field Catalog in step 1. In my example, I define the product allocation at the product, plant, and customer levels.

Figure 6

Select characteristics for the Product alloc. group click here to view a larger version of this image

Step 4. Define the consumption period. The consumption period defines the time period for which the system checks the allocation in the planning area. The period is based on the material availability date of the order mentioned in step 3. In my example, I specified that the allocation would check for availability two weeks backwards (Bwd Cons. in Figure 7) and three weeks forward (Fwd Cons.) No past periods are considered (W/oPastPer) and only active periods (ActiveOnly) are checked for backwards consumption.

Figure 7

Define the Consumption Period click here to view a larger version of this image

Here are the implications of the settings for the consumption period. Consider an example in which a sales order comes in with the material availability date in the future, let’s say two weeks from now.

The sales order looks for allocations in that third week first. If it does not find enough, it starts looking for the allocations in the second week and the current week, in that order. If not enough allocated product is available to meet the requirement, it looks for allocations from the fourth week onward using the forward consumption logic (for another three periods including the fourth period).

In another case, consider an order that comes in for a material availability date in the current week. If allocations do not meet the requirement in the current week, the system does not look for allocations in the previous week, since it is already in the past. However, it looks for availability in the future weeks based on the defined settings.

Step 5. Define the allocation procedure. Use transaction SPRO and follow menu path Advanced Planning and Optimization> Global Available to Promise>Product Allocations>Maintain Product Allocation Procedure. Define a name for the Prod. Alloc. Proce (ALLOBJ in Figure 8) and a descriptive name under Procedure name. Note that the Cumulative check is selected, which means that the check is performed against the remaining product allocation quantity still available. It includes any unused quantities from past periods. The idea is that customer orders may be more or less in a certain period than the allocation quantity just for that period. The system restricts the order from confirmation only when the aggregated quantities of allocation (over the consumption period) fall short of the requested quantity.

Figure 8

Define the allocation procedure

You set the allocation procedure via the ATP tab shown in Figure 9. It corresponds to the product location master (or product master if the allocation procedure is not location dependent). In my example, I selected the allocation procedure ALLOBJ in the Loc.-dep.proced field. When you define the master data for a product at a particular location, you also define the fields of the product location master and vice versa. From the screen in Figure 9, you also define the product ALLOC_ PROD at the location DC1.

Figure 9

Assign the allocation procedure to the product

Step 6. Define the steps for the allocation procedure. The allocation procedure can be more than one step depending on whether it involves checking more than one allocation group. In my example, I checked against one product allocation group: ALLOBJ, which was defined in step 3. I selected a masking characteristic # under the column Wild. in Figure 10. The practical implication is that for an allocated product the allocation check is performed for all customers.

Figure 10

Define the steps of the allocation procedure

However, maintaining allocations for smaller customers can be time-consuming and inefficient, as orders from such customers can be erratic and ad hoc. It is only practical to maintain allocations for major customers. Therefore I created a leftover combination with the wild card as the customer. When a sales order comes in for such a small customer, it does not find a match since the combination does not exist in the planning area. It therefore looks for allocations corresponding to the wild card customer (maintained as #). In the planning area, you maintain the allocation for the product, the plant, and the customer #.

Step 7. Set the allocation procedure to the correct product allocation object and the date range for which it is active (Figure 11). I set the factor to 1.00, which means that a one-to-one correspondence exists between the requested quantity (in the sales order) and allocation quantity. The validity period for the allocation object in the allocation period is defined (12/31/2006 in my example) and selection of the Active indicator makes it active.

Figure 11

Link the allocation procedure and allocation object

Step 8. Maintain the connection to the planning area. Use transaction SPRO and follow menu path Advanced Planning and Optimization>Global Available to Promise>Product Allocations>Maintain Connection to Planning Area. This step involves the all-important link of the product allocation group to the allocation planning area. The product allocation group ALLOBJ is linked to the Planning Area PROD_ALLOC_PLAN. The planning version (Plng V in Figure 12) is selected as 000, which means the active version of the plan is used for the allocation check. The time bucket profile is chosen as W corresponding to the weekly buckets in which the planning area maintains the allocations.

Figure 12

Link the Product allocation group to the Planning Area

Step 9. Define the characteristic mapping between the characteristics of the product allocation group and the characteristics of the allocation planning area. Once the link between the product allocation group and the planning area is made as in step 7, each of the characteristics of the product allocation group is mapped to the characteristics of the planning area. The Charact. column on the left in Figure 13 corresponds to the characteristics of the product allocation group. The InfoObject on the right corresponds to the objects in the planning area.

Figure 13

Map the characteristics of the product allocation group to the planning area

Note that the sold-to (KUNNR) partner function in the sales order links to the customer (A_CUSTOM) field of the allocation planning object structure. Figure 13 also shows the linkages for the product allocation object (KONOB), product (MATNR), and the plant (WERKS).

Step 10. Define how the key figures in the product allocation group are linked to the key figures in the planning area (Figure 14). When you perform an allocation check for a sales order, you have to define the relevant order quantity key figure that checks against the corresponding planning area key figure. Once the allocation is saved, you also have to define what key figure in the planning area is updated. That indicates what the remaining allocation is.

Figure 14

Link the key figures of the product allocation group to that of the planning area

In the Key figure column in Figure 14, select the relevant field via the drop-down menu. AEMENGE corresponds to the requested quantity in the sales order. For the InfoObject column, select the relevant key figure from the planning area as ALLOCQTY (the allocation plan key figure of the planning area). In the next row select KCQTY. It corresponds to the confirmation quantity that is sent back to the R/3 system. Link it to A_ALLOCNS in the planning area, which corresponds to the consumed allocation key figure of the planning area. As sales orders are confirmed, it also updates key figure A_ALLOCNS in the planning area.

Step 11. Define the order of check instructions. Once you complete the product allocation setting, define how the product allocation check is performed in conjunction with other availability checks for that order, such as product check, forecast check, or rule-based availability check. In my example the product allocation check is done first and the result of this check is used to check for product availability (Figure 15).

Figure 15

Maintain check instructions

Once you make these settings, when a sales order is created in an R/3 environment, the system performs an availability check in the APO environment. It checks for product allocations in the Allocation Planning area.