• The document creation date (First In, First Out [FIFO])
  
  
• The material availability date
  
  
• Customer priority
  
  
• Delivery priority (in the case of rush orders)

How the company handled each order was especially important for products that were in short supply because it would be impossible to fill all the sales orders at once. Furthermore, the sort criteria could change based on the company’s business needs. For example, it considered customer service very important for certain key customers, but it also wanted the option to be able to treat all customers equally with faster inventory turns.

You can meet these requirements by setting the sort profile and filter type for BOP. I will discuss how to configure this in Advanced Planning and Optimization (APO) 4.0. During this implementation, we encountered some issues when we used the material availability date as a sort criterion. We were able to work around this with a user exit priority, which I will explain. If you are familiar with a similar rescheduling functionality in R/3 Enterprise (Release 4.7), refer to the sidebar “Comparison with R/3 Rescheduling” to evaluate the differences between BOP in APO and rescheduling in R/3.

For the purposes of this discussion, assume that Available-to-Promise (ATP) checks happen in the APO system. Although the system has the functionality to change the confirmations on the sales orders interactively through the interactive BOP transaction, this is a manual process. Alternatively, you can schedule it in batch processing for specified times, which is what I did.

Business Scenarios

Here are three examples of when you could use the sort order profile in BOP. In my examples, users can create or change sales orders at any time. The ATP check happens at the point of sales order creation or change and results in a confirmed quantity and date.

Scenario A

Consider a scenario in which you have two sales orders (1 and 2) that came in from two different customers (A and B) for an identical quantity of 50 each for the same product X. You create sales order 1 for customer A first and sales order 2 for customer B second. You have only 50 pieces available in the plant and the system performs the ATP check in the sales orders based on product availability only. The material availability date for both of the sales orders is the same. In this example, you have to determine which order receives the confirmation. Recall that the order you created first is sales order 1 for customer A. However, what if the business needed to prioritize sending products to customer B over customer A?

Scenario B

In this scenario, the product availability situation changed after the system performed the ATP check. For example, this could happen if you received products that you ordered from a vendor with a PO. Another example is if a cycle count determines that you have only 40 pieces available when you create the orders, rather than 50 pieces.

Scenario C

Say product allocations are based on the product and customer. If the allocation quantity for that product and customer changes, the corresponding confirmations on the sales orders (for that customer) would also have to change based on the new allocation quantity. To update the sales order confirmations for the three scenarios I described, let’s take a look at the batch BOP option in APO.

Set Up the Sort Profile in APO

The batch BOP functionality looks at all of the open orders in the system (those for which the system has not created a delivery). The system then sorts them through a predefined criterion called the sort profile. You can remove the previous confirmations on these orders and perform the ATP checks again for the sales orders based on the sequence you define in the sort profile.

For example, I defined a sort profile I called ALTERNATE1. Use transaction code SPRO and follow menu path mySAP SCM - Implementation Guide>Advanced Planning and Optimization>Global Available-To-Promise>Tools>Define Sort Profile. The fields shown in Figure 1 appear on the sort profile screen.

• Field name corresponds to the criterion that you want to use to sort the sales orders
  
  
• Field Label is the description of the field name
  
  
• Sequence corresponds to the priority for the field name. The lowest in the sequence means the system sorts sales orders using the field name first. In my example, Location is the first criterion for sorting. This corresponds to the sold-to partner function in the sales order. The system sequences all of the sales orders based on the location first. The system then sorts sales orders that belong to the same location based on the delivery priority.

Figure 1

Define the sort profile

By clicking on the change sort icon in the Change Sort field, you can change whether the system sorts the sales orders based on ascending or descending values, or if it uses a special sort value. This corresponds to the values in the Sort order column. When the sort order is Special sor, then the Display Sort column shows a lens icon. When I click on Special sor under the Sort order field corresponding to the Location, the system displays the screen shown in Figure 2.

Figure 2

Define the special sorting

The screen shows the customer numbers based on the order in which the system sorts the sales order numbers. The system considers first the sales order for the first location that you defined in the special sort when BOP runs. You define the special sort by using transaction SPRO and following menu path mySAP SCM - Implementation Guide>Advanced Planning and Optimization>Global Available-To-Promise>Tools>Define Special Sorting. Figure 2 shows the fields available for the special sort. Click on the Customer folder under the Dialog Structure menu to apply the special sort. The system lists the individual customer numbers based on their priority. You would use this kind of sorting if you were to follow a customer-based prioritization as I described in scenario A earlier.

Expanding on the sort profile ALTERNATE1 a little more, if you choose the Ascending sort order for the Delivery Priority field in Figure 1, then the system sorts the sales order based on the ascending value. In other words, the system considers sales orders with a delivery priority of 1 first when it performs the ATP check. In this case, I assume that the sales order has the same value for the location or I did not define the location corresponding to the sales order in the special sort. If two different orders have the same delivery priority, the system sorts them based on the material availability date. It takes the one with the earlier material availability date first for the ATP check.

The sort profile defines the prioritization scheme in which the system considers sales orders for the availability check. It also defines which sales orders are first in line, especially when you have a constrained supply for the material. For the purposes of the discussion, I am reconfirming the sales orders and not simply trying to remove the confirmations from the sales orders through the BOP run. The sequencing can serve various and sometimes conflicting business objectives. If you consider certain customers to be clearly more important than others, then you could prioritize based on the customers. This could lead to the business holding on to the inventory to satisfy the more important customers. However, that may conflict with business inventory objectives.

If you base the prioritization on the material availability date first, then the system supports the FIFO method of satisfying the sales orders. This leads to faster inventory turnaround, but may not meet the other objective of satisfying the more important customers. This also leads to more complex ways of sequencing, which require the system to consider the combination of the two fields at the same time. This leads to the use of a user exit priority in sequencing the sales orders.

In this implementation, the faster inventory turnaround was more important, so the material availability date was the first criterion for sorting. However, when the system used the material availability date, it ran into a limitation, which then required it to use a user exit priority, as I explain in the next section.

Set Up the User Exit Priority

Consider an example in which you use the material availability date as the first sort criterion. When the system creates a sales order, the system calculates a material availability date based on the time it takes for pick/pack, load, and transportation. In this example, the total time required is seven days. What happens if you are out of stock of the product in the sales order? The scenario described here ties closely to the scenario B that I described earlier, in which running BOP aligns the confirmations on the sales orders with changes in product availability.

A user creates the sales order 1 on 12/01/2006 with a requested delivery date of 12/14/2006 and the requested quantity of 60 pieces. The pick/pack, load, and transportation time is seven days, so the system calculates the material availability date as 12/07/2006. However, you do not have any stock on hand to fill the order, so the system does not confirm it (Table 1).

Four days later (12/05/2006), a user creates sales order 2 for 200 of the same product with a requested delivery date of 12/18/2006. The system calculates the material availability date as 12/11/2006. The stock status hasn’t changed, so the system does not confirm this sales order either (Table 2).

Nine days later (12/14/06), the stock situation changes from 0 to 20. Sales order number 1 has the earlier material availability date, so when BOP runs, the order gets a partial confirmation for 20 of the 60 pieces (Table 3). Note that the BOP run updates the material availability date to the current date. You have no available quantity for sales order 2, so the system does not update this sales order’s status. The material availability date for sales order 2 does not change.

In this example, you ship the 20 pieces in sales order 1 out the same day, 12/14/06 (assuming the customer accepts a partial delivery of its order). A day later, you receive 50 more pieces of the same product. Now, because sales order 2 has an earlier material availability date, BOP considers it first and confirms 50 of the 200 pieces for this order and updates the material availability date (Table 4).

This leads to an out-of-sequence confirmation in which the order that was placed later (shaded) receives a confirmation ahead of the order that came in earlier. To rectify this, the system should use the sales order’s original material availability date instead. For this, select a user exit priority as the criterion by following user exit EXIT_/SAPAPO/SAPLBOP_SORT_020. The system updates the user exit priority with the original material availability date by using the user exit in BOP to sort the sales orders.

Set Up the Filter Type in APO

In addition to configuring the sort profile the criterion, you can configure BOP in APO through the filter type definition. Use transaction code SPRO and follow menu path mySAP SCM - Implementation Guide>Advanced Planning and Optimization>Global Available-To-Promise>Tools>Maintain Filter Type (Figure 3). You can use the Filter Type to select the Order Categories and the Criteria (characteristics) by which the system selects the sales order for BOP.

Figure 3

Define the Filter Type

Click on the New Entries button to create a new filter type. Give it a name, such as USER DEFINED (Figure 4). Then choose the order categories for which BOP should run. The right side of the screen shows the order categories that you can select in the filter type, such as Customer inquiry and Contract. Double-click on the Order Categories folder to view the category selection screen. For my example, I selected Sales order, SD scheduling agreement, and Delivery w/o charge because they relate to actual orders.

Figure 4

Define the Order Categories for the filter type

Next, double-click on the Criteria folder in Figure 4 to select the characteristics that you want for the sales orders for BOP (Figure 5). The criteria available for sales order line items from the list of various fields are visible in the right side of the screen. I selected Product, Distribution center, and Item Category because these were the criteria by which I wanted to filter the sales orders that would be selected for the BOP run. The Product field allows you to select certain critical models only for the BOP run or allow for the system to perform BOP runs in parallel by selecting different products for each BOP run, especially when you need to run it for several products. The Distribution center allows you to focus on more important distribution centers, and the Item Category allows you to exclude those item categories that are not relevant from a BOP perspective.

Figure 5

Define the Criteria for the filter type

How BOP Uses Sort Profile and Filter Type

Now that I’ve shown you how to configure the sort profile and filter, let’s take a look at how the system uses them in BOP. Follow menu path Global ATP>Back Order Processing>Back Order Processing in the Background (Figure 6). On this screen, you provide a Name for the BOP run. In my example, I named it Critical Model Run. I’ll go through each of the tabs in this screen and explain the BOP options each one offers.

Figure 6

Define the batch backorder processing variant

Click on the Worklist tab to select the Filter type and Sort profile that you configured earlier. For example, I chose USER DEFINED and ALTERNATE1.

Click on the Filter button to access the FILTER USER DEFINED screen in Figure 7. In this screen, enter values that correspond to the fields that you chose for the filter type. Recall in Figure 5 that I selected Product, Distribution center, and Item Category. In Figure 7, I entered DS* in the Product field, which means to select all the products that start with DS. I entered 0000 for the Distribution center and excluded any custom-made sales order line items by entering TAM (configurable item at the component level) for the Item Category.

Figure 7

Define the filter variant

Click on the Confirmation situation tab to view the screen in Figure 8, which displays the options for considering and filtering the orders that the system should consider as part of the BOP run. In my example, I selected the Backorders (date) check box so when BOP runs, the system considers orders that have a material availability date in the past.

Figure 8

Control the selection of sales orders based on the confirmation situation

Return to the screen shown in Figure 7 and save these settings as a variant for the filter type. This brings up the screen where you can assign a name for the variant. In the Variant field, I named these settings CRITICAL MODEL. After you name the settings, return to Figure 7 and click on the Display list button to bring up all the sales orders that correspond to the filter variant CRITICAL MODEL (Figure 9). The system sorts these sales orders using the sort profile when BOP runs.

Figure 9

Display the worklist for the filter variant

Next, return to the screen in Figure 6 and click on the Parameters Process tab, which brings up Figure 10. On this screen, you define some of the parameters that influence the results of the BOP, such as complete reconfirmations of all the sales orders or whether the system is running BOP in simulation mode.

Figure 10

Parameters for the BOP run

Under the New distribution for tab, the fields for Product Check and Product allocations determine whether to redistribute the existing confirmation quantities for the sales orders that the system confirmed before the BOP run. If you leave these check boxes unchecked, then the system releases the confirmation only for the sales order that the system is checking — not for the sales orders considered for the BOP run. In this case, the system is more likely to retain the original confirmation situation. If a shortage occurs, the first sales order that the system selects based on the sort profile is more likely to lose its confirmation. In my example, I selected Product Check and Product allocations because I want to release all of the confirmations of the sales orders already confirmed (and the confirmations for the product allocations) and reconfirm them again. Checking the product allocations would ensure that you get the best results as in the scenario C I described earlier.

In the Customizing tab, if you select Read procedure, then the system reads the allocation procedure from the product master. Sometimes the product’s allocation procedure changes after you create the sales order. When the BOP run happens for existing sales orders, the system reads the allocation procedure from the product master. In my example, I reconfirm the existing sales orders based on the updated allocation procedure in the product master. Read check mode has the same implication for the check mode in the product master. This performs the check based on the check mode selected in the sales order.

The Execution Mode tab offers you options for the BOP run. You can carry out a Simulation run without updating the sales orders. Alternatively, you can perform an actual Update. Furthermore, by selecting the With postprocessing option you can store the results in a buffer and update them through interactive BOP.

In this case, I want BOP to update the sales orders. In the screen in Figure 6, click on the Parameters Check tab to select the orders for which the system should cancel the confirmations. You can select these sales orders by using an additional filter type and filter variant. These orders are not considered in BOP for confirmations.

Frequency of BOP Run

BOP in APO is flexible — you can set it up to meet your business requirements. An important question is: How frequently should you run BOP? While it’s tempting to think that you should run this as frequently as possible, in our implementation only once a day was practical. Running BOP for all the products in the sales orders is a time-consuming activity, even when we had set up jobs that we could run in parallel for different sets of products. Another consideration was not to run BOP during the day, when most of the sales orders are created.

You should also consider the frequency at which you receive goods at the warehouse with changes in product availability. Running BOP more frequently than once a night was restricted to critical models for which we received goods more frequently than once a day. We also ran BOP more frequently in the busy season to ensure that we met customers’ on-time delivery requirements.

In environments in which you use Production Planning (PP), you could trigger BOP based on a planning file entry determined by the planning procedure assigned to the product. The planning procedure configuration determines what triggers a planning file entry, such as a change in the stock situation for a product, or a creation or change of production orders. In this case, you use the standard filter type SAP_NETCHANGE in the BOP run. You run BOP at frequent intervals only for those products that have a planning file entry. Alternatively, you can run BOP after a production planning run. You could use another standard filter type, SAP_ALERT, in environments where you use Transportation Planning and Vehicle Scheduling (TP/VS).

Comparison with R/3 Rescheduling

In R/3, rescheduling is the corresponding transaction for executing BOP in batch processing. If you are familiar with the rescheduling transaction in R/3, you can see how the two processes compare. Many find rescheduling to be more limited — this is a key reason why most companies move from the basic R/3 functionality to the more advanced and versatile functionality in APO. Access the rescheduling transaction in R/3 by following menu path Logistics>Sales and Distribution>Sales>Backorders>Rescheduling>Execute.

Filter Type Comparison

As shown in Figure 1, the selection criteria in R/3 are limited to just Material and Plant. You have limited options to select the document types. The choices are restricted to sales documents or stock transfer documents. As you can see in Figure 4 in the main article, you can select specific document categories for this process in APO.

Figure 1

Rescheduling in R/3

Sort Profile Comparison

In general, APO offers the flexibility in how you sort a field, whether ascending, descending, or a special sort. This is not possible in R/3. In addition, R/3 offers limited sort criteria, with the choices restricted to:

• Document category (sales documents or stock transfer orders): In APO, the system can take the ATP categories in a specific sequence through a special sort or in a simple ascending or descending sequence.
  
  
• Delivery priority: Common to R/3 and APO
  
  
• Date: In R/3 you can choose between sorting the item by creation date or by requested delivery date. In contrast, APO offers the additional option of material availability date.
  
  
• Document number: Same in R/3 and APO
  
  
• Document item: Same in R/3 and APO

Order Selection Based on Confirmation Status

In R/3, you can choose to run rescheduling based on unconfirmed sales orders. In APO, you have many options for controlling orders based on the confirmation status, as shown in Figure 8 in the main article.