Chapter 6: Availability Check, Transfer of Requirements, and Backorders

Promising accurate and reliable dates for delivery to your customers is a key element of the order fulfillment process in today’s competitive environment. In the SAP ERP software, the availability check functionality provides this accuracy and reliability. In this chapter, we will discuss the availability check functionality in detail including its relationship to transfer of requirements, backorder processing and order rescheduling. During these discussions, we will also walk you through the required customization settings for these functions and, as always, provide Galaxy Musical Instruments case studies to further clarify the topics.

Meaning and Relationship

The schedule line in a sales order contains information about the quantities of a material ordered by the customer and the corresponding delivery date requested by the customer for delivering the material. In the SAP ERP world, the delivery date quoted by the customer is called the customer-requested delivery date. When taken together with the delivery quantity requested by customer for such a date, the term used is material requirement. Material requirement–related information is vital to the MRP department’s ability to make production/procurement-related decisions. In the SAP system, this information is transferred to MRP using the transfer of requirements (TOR). You can transfer requirements either individually or collectively. An individual requirement transfers the material demand for each schedule line to MRP, whereas a collective requirement transfers summarized data on a daily or weekly basis to MRP. Accordingly, you can trace back an individual requirement to the order from which it originated, while the same is not possible in a collective requirement.

An availability check (AC), on the other hand, is the functionality that helps you confirm the schedule line in an order and thus facilitate the customer’s order confirmation/promise process. When carried out in the context of a sales order, the AC process checks the stock availability for the material in the delivering plant/warehouse. If sufficient quantities are available to meet the customer-requested delivery date, the AC then confirms the customer-requested delivery date on the schedule line. In situations where the requested delivery date cannot be met because of a shortage of stock, the AC is also capable of proposing a future date when the delivery quantities can be confirmed for an order. While calculating, the availability check also considers various lead times such as procurement/production lead time, plant/warehouse processing time (including aspects such as pick/pack, load/unload, transportation planning time, and goods issue/receipt time), and shipment transit time. This helps you make accurate and reliable calculations about the delivery dates that you can promise to the customer. This also provides a visibility into manufacturing/procurement capacity, warehouse processing capacity, and transportation capacity.

The TOR functionality is a prerequisite for carrying out the availability check. You can configure TOR to work without an availability check but not the other way around. This is really beneficial in scenarios where you don’t want the availability check to happen for the material but want the requirement to be transferred to MRP for production/procurement decision making. There is no hard-and-fast rule for what materials should be included for both the availability check and the transfer of requirements, what should be included only for the transfer of requirements, or what materials should be excluded from both the transfer of requirements and the availability check. The decision depends upon the business requirements and the way MRP strategies are used to handle such requirements. Therefore, it is always best that you work closely with your PP and MM counterparts when configuring the transfer of requirements and the availability check in the SAP ERP software. A few common examples of where the availability check is generally switched off are KANBAN-relevant materials, bulk materials, slow-moving inventory materials, and so on, where you control the procurement/production-related decisions using other planning strategies and methods available in the MM/PP application of the SAP ERP software.

Types of Availability Check

There are three types of availability checks:

• Check against available-to-promise quantities
• Check against product allocation
• Check against planning

Check Based on Available-to-Promise Quantities

Here the check is performed against available-to-promise (ATP) quantities. This check considers the currently available stock and also the stock that will be available in the near future for availability check calculations. In equation form, this can be depicted as follows:

Check against ATP = Available stock + Future receipts – Future issues

where

• Available stock refers to the stock available in hand at the delivering plant/warehouse.
• Future receipts represent all the inward movement of goods that can add stock in the delivering plant/warehouse. Purchase order, production order and stock transfer order are a few examples of documents that trigger inward movement of stock.
• Future issues are all the outward movement of goods that can lead to the consumption of stock from the delivering plant/warehouse. Sales orders, deliveries, stock transfer orders, and assembly orders are a few examples of documents that trigger outward movement of stock. Production order, assembly order, and stock transfer order play dual roles, because they are responsible for the addition as well as consumption of stock.

This type of check is performed dynamically for each transaction. In SAP SD, you can perform this check with or without replenishment lead time (RLT), which is the time to refill/replenish the inventory of the delivering plant.

Check Based on Product Allocation

Unlike the check based on ATP, in which allocation happens on a first-come, first-served basis, here you set up a maximum limit for the material quantity a customer can place order for. This check helps with the allocation of products to certain customers/regions so as to control the overall distribution. This is really helpful in scenarios such as new product launches, high-demand/hot sale products with limited supply, and products with higher lead times for production for which you want to restrict the stock quantity per customer so as to control the distribution of such products to the customer.

Check Based on Planning

Here the check is performed against independent requirements that are generated from demand-planning applications such as SAP APO-DP. These requirements are generally created for anonymous markets and are not customer-specific.

How the Availability Check Process Works

The availability check process confirms the delivery date on the schedule line in an order. To confirm this date, the system uses the material availability date (MAD) as the basis. This is the date on which the requested quantities for the material should be available to meet the customer-requested delivery date. The system determines the material availability date by calculating backward from the customer-requested delivery date and subtracting the delivering plant/warehouse processing time (pick/pack time, lead time for transportation planning, loading time) and transit time. This process is called backward scheduling.

The system then checks whether sufficient quantities of the requested material are available for this material availability date so as to make the delivery as per the customer-requested delivery date. If the requested quantities are not available as of the material availability date, the system performs another search in the future, taking into consideration the planned receipts and issues (if allowed in customization). It then redetermines the material availability date as the date in the future on which the sufficient quantities of the requested material will be available. Once the system determines the material availability date on which the requested quantities of material are available or will be available, it starts calculating forward and adding the time for pick/pack, transportation planning, loading, and transit to the material availability date and proposes or confirms the final date thus calculated as the confirmed schedule line date on the order. This process is called forward scheduling.

In equation form, this backward/forward scheduling can be represented as follows:

Schedule line confirmation = Material availability date + Pick/pack time + Lead time for transportation planning + Loading time + Transit time

Complete Delivery and Availability Check

Figure 6-1 depicts the concept we just discussed. As you can see, the customer placed an order on the 9th with a requested delivery date of the 14th. The available stock in the warehouse was 50 units with a planned receipt for another 50 units by the 10th. The warehouse processing time for the pick, pack, load, and goods issue activities takes a total of one day, and two days are needed for shipping time. The system first starts calculating backward from the 14th and determines the material availability date as the 11th. Because sufficient stocks will be available on this date (50 available on the 9th and 50 expected to be received into unrestricted stock by the 10th), the system performs forward scheduling from the material availability date, adding the warehouse processing time of one day and the shipping time of two days, and thereby confirms the schedule line for the 14th for 100 units.

Figure 6-2 shows another variation of the same example, wherein the material availability date is already past because the customer ordered on the 9th with a requested delivery date of the 11th. The system performs backward scheduling and determines the material availability date as the 8th, which has already passed, and therefore it considers the current date, the 9th, as the material availability date. Sufficient quantities are not available on this date, and therefore the system redetermines the material availability date as the 10th, to which the system then adds three days of warehouse processing and shipping time and proposes the 13th as the confirmation date for the schedule line.

Partial Delivery and Availability Check

The scenario that you just saw was an example of the scenario wherein the customer will accept delivery for the goods in full only. What if the customer agrees to partial delivery? Figure 6-3 answers this very question by showing the influence of a partial delivery scenario on the availability check results. You can maintain the indicator to allow partial deliveries and the allowed number of partial deliveries directly in the sales document’s “Shipping tab” or in the “Shipping tab” of the customer master sales data view. When you create a sales order, the partial delivery indicator defaults from the customer master data to the sales document. You can change this value in the sales document (if required).

Now, if all other factors remain unchanged and if the customer agrees to partial delivery, the results will be as shown in Figure 6-3. As you can see from the figure, since the customer agrees to a partial delivery of goods, the system confirmed two schedule lines for two different dates. Against the requested delivery date of the 11th, 50 units were available on the 9th, and the receipt of the balance (50) is planned for the 10th. Adding three days for the pick, pack, post goods issue (PGI), and shipment time to these two availability dates, the system proposes the confirmation date as the 12th and the 13th.

One-Time Delivery and Availability Check

Another variation is also possible, wherein the customer agrees to take a one-time delivery of goods. In that scenario, the system confirms the quantities of the materials that are available for the customer-requested delivery date and cancels the balance of the order. Figure 6-4 shows this scenario.

Availability Check with Replenishment Lead Time

In the SAP SD application, you can perform an availability check with or without replenishment lead time. As mentioned earlier, the RLT is the lead time to refill/replenish the inventory in the delivering plant/warehouse. In the case of in-house production, the RLT takes into consideration the production time. For external procurement, the RLT takes into consideration the goods receipt (GR) time.

Let’s reconsider our example from Figure 6-1 with an RLT of two days, as represented by Figure 6-5. As you can see, one more order is received on the 9th for 120 quantities, and delivery is requested by the 14th. The system starts calculating backward and determines the MAD as the 11th. On this date, the system takes a look at the current situation and sees that the stock is not available (the stock in hand of 50 units and the 50 expected to be received are already consumed by 100 units in the order). Since there is no stock and an RLT is built into the availability check, the system starts calculating the time to replenish the stock from the current date and determines that the stock will be available by the 11th, which is the MAD. Therefore, the system will confirm the date of the 14th for the order.

On the contrary, in Figure 6-6, the RLT is not considered. An order is received on the 9th for 60 units with a requested delivery date of the 14th. Another stock receipt is expected on the 12th. The system starts calculating backward and calculates the 11th as MAD. On this date, the stock quantity is not available, but a quantity of 50 will be available by the 12th, so the MAD for these 50 units is taken as the 12th, giving the 15th as the confirmation date. The balance (10 units) cannot be confirmed, because without a lead time, the system cannot say when the quantities will be available in stock, and thus the balance quantity falls into backorder status.

A common example of when you don’t need RLT is consignment stock processing. In that case, you perform an availability check against the special stock, and thus there is no need for RLT. We will discuss more about consignment processing and its relationship to special stock in Chapter 7, “Sales.”

Customizing the Availability Check and Transfer of Requirements

Both the availability check and transfer of requirements are controlled via a common set of customizing elements. These elements are arranged in six simple customization steps, as shown in Figure 6-7. Steps 1 to 5 are common to both the availability check and the transfer of requirements. Step 6 is required only for the availability check. In the following sections, we’ll walk you through each of these customization steps in detail.

Step 1: Activate Transfer of Requirements and Availability Check at Requirement Class Level

You start the customization activity for the availability check and transfer of requirements functions by activating these functions at the requirement class level. A requirement class controls MRP and other requirement-relevant functions such as requirement consumption strategy, requirement planning strategy, and so on. Once activated at this level, the transfer of requirements and availability check functions become globally activated for that requirement class in the SAP ERP software. You can further fine-tune to allow/disallow these two functions for a sales document type by activating/deactivating the two functions at the schedule line category level.

To activate/deactivate the availability check and transfer of requirements at the requirement class level, use transaction code OVZG, or follow the menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer of Requirements ⇒ Transfer Of Requirements ⇒ Define Requirement Classes. Figure 6-8 represents the customization overview and detail screens for requirement class 041. Requirement class 041 is delivered in the SAP ERP software as a preconfigured requirement class for use with the SD application. The two fields that interest us in Figure 6-8 are check boxes for the availability check and transfer of requirements. Select these two check boxes if you want to activate the availability check and transfer of requirements for your requirement class. In requirement class 041, these two check boxes are preselected by SAP.

The customization screen also allows you to create your own requirement class. To do so, choose up to a four-character identifier key with a Z prefix and a meaningful description. Make selections into the relevant field as per your business requirements, and save your entry. Since the requirement class is a core of the PP/MM area with downstream impact on MRP calculations, it is advisable to work with a PP/MM consultant whenever you make any changes to a requirement class or create a new requirement class. In this book, we’re only discussing the customization fields in the requirement class that are relevant for the availability check and transfer of requirements.

Step 2: Define Requirement Type and Assign a Requirement Class to a Requirement Type

A requirement type is a four-character key that uniquely identifies a requirement and helps differentiate requirements from one another. The transaction code is OVZH, and the menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer Of Requirements ⇒ Transfer Of Requirements ⇒ Define Requirement Types. Figure 6-9 shows the customization settings for requirement type 041 and its assignment to requirement class 041.

To define your own requirement type, click the New Entries button on the menu bar, and provide up to a four-character identification key with a meaningful description. Maintain the requirement class in the field next to the requirement type (as shown in Figure 6-9), and save your entry. Always remember that a requirement type can have only one requirement class assigned to it, whereas a requirement class can be assigned to multiple requirement types.

Step 3: Set Up Determination Rule for TOR

In this customization step, you set up the rules for determining the requirement type based on the item category and MRP type combination and also the rules to determine the requirement type based on the item category only. The transaction code for this step is OVZI, and the menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer Of Requirements ⇒ Transfer Of Requirements ⇒ Determination Of Requirement Type Using Transaction. Figure 6-10 shows the customization screen for the rules setup.

This screen is a subset of the VOV4 customization screen. Transaction VOV4 is used to define the determination rule for the schedule line category using a combination of an item category and an MRP type as a determination key. If you want to maintain the requirement type determination rule in OVZI for a new item category or an item category and MRP type combination, you need to maintain it as a valid combination key in VOV4, before you can start using it in OVZI.

To maintain your entry in OVZI, select the key combination for the item category and MRP type or just the item category to which you want to assign the requirement type. Now enter your requirement type identification key in the Requirement Type field corresponding to your selected key combination. For reference purposes, Figure 6-10 shows the customization setup for the determination of requirement type 041.

Step 4: Activate Transfer of Requirement and Availability Check at Schedule Line Category Level

This customization step allows further fine-tuning of the availability check and transfer of requirements settings. After activating the availability check or transfer of requirements at the requirement class level, if you don’t want these functions to take place for a sales document type, you can deactivate these functions at the schedule line level. Always remember that activating the availability check and transfer of requirements at the requirement class level is a must before you can fine-tune them at the schedule line level.

Figure 6-11 represents the customization screen for schedule line level activation. The transaction code is OVZ8, and the menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer Of Requirements ⇒ Transfer Of Requirements ⇒ Define Procedure For Each Schedule Line Category.

You can also activate the availability check and transfer of requirements using the schedule line category maintenance transaction VOV6.

Step 5: Define Checking Group

A checking group is an important controlling element for the transfer of requirements and availability check processes. Whether the system should generate an individual or collective requirement, whether an availability check should happen with or without accumulation, and whether there should be no availability check at all are all controlled by the checking group function. You can define a checking group using transaction code OVZ2 or following the menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer of Requirements ⇒ Availability Check ⇒ Availability Check With ATP Logic ⇒ Define Checking Groups. Figure 6-12 shows the customization screen for defining a checking group. The entries in columns Av and Description show the checking group being configured and its description.

Let’s quickly go through the other fields available on this customization screen:

Total Sales Requirements The field shown as TotalSales in Figure 6-12 controls the type of requirement that the SAP system generates and passes to MRP during sales order processing. Available values are A, B, C, and D. Choose A if you want to generate individual requirements per sales document, B if you want summarized requirements per day, C if you want weekly summarized requirements with a requirement date as Monday of the current week, and D if you want the weekly summarized requirements with a requirement date as Monday of the following week.

Total Delivery Requirements The field shown as TotDlvReqs in Figure 6-12 controls the type of requirement that the SAP system generates and passes to MRP during delivery processing. As with the previous field, the available values are A, B, C, and D. Choose A if you want to generate individual requirements per delivery document, B if you want summarized requirements per day, C if you want weekly summarized requirements with a requirement date as Monday of the current week, and D if you want the weekly summarized requirements with a requirement date as Monday of the following week.

Block QtRq This indicator is really helpful in preventing the problems that arise when more than one user carries out an availability check on the same material at the same time. When set, this indicator blocks the confirmed quantities and in turn avoids duplicate assignment of the same stock to multiple orders. This way, you can carry out the availability check for the same material/plant simultaneously without causing any duplicate or wrong assignments of stock. Always remember that although this indicator ensures accuracy, it also slows down performance, because each time the check is carried out, the SAP ERP system has to perform an extra step to block the confirmed quantities.

No Check Not all the materials require an availability check. For instance, when materials are controlled via the KANBAN process, KANBAN makes sure that enough material is always available. Similarly, there might be certain low value or very low inventory turnover items that you might want to exclude from the availability check. The No Check indicator box serves the purpose in those scenarios. When you select it for a checking group and assign that checking group in the material master, that material is excluded from all further availability check processing. The standard SAP system offers checking group KP to handle such operations.

Accumulation The field shown as Accumul. in Figure 6-12 helps you cumulate the confirmed quantities. Without accumulation, there is a chance that SAP will confirm more quantities to orders than are available to promise. Figure 6-13 shows the example scenario where order 1 got 100 units confirmed based on the available-to-promise situation at that point in time (available stock in hand [50 units] + planned receipt [50 units]). Later, the planned receipt was delayed from the 10th to the 12th. Since this delay of the planned receipt date does not retrigger the availability check for sales orders by itself, order 1 still shows confirmed for 100 units, whereas in reality, it has only 50 units available. Order 2 (50 units) was received on the 11th and also got confirmed against the planned receipt 1.

With the cumulation of quantities, you can avoid these inconsistencies. These are the available choices for this field:

0: No accumulation Choose this when you don’t want to use accumulation. If you don’t use accumulation of quantities, you can still avoid the inconsistencies (shown in Figure 6-13) by running the reschedule and backorder processing transactions provided by SAP. These transactions are explained later in this chapter.

1: Accumulation of confirmed quantity when created and changed Choose this when you want to use accumulation of confirmed quantities during sales order creation and while making any changes to the already confirmed quantities in a sales order. This means that for new orders to be confirmed, the sum of the receipts has to be more than the sum of the confirmed quantities.

2: Required quantity when created, no accumulation when changed Choose this when you want to use accumulation of the confirmed quantities during the sales order creation only. No accumulation will happen when you change the sales order.

3: Required quantity when created, confirm quantity when changed This is the recommended setting, because this allows you to accumulate the open requirement quantities during sales order creation and the confirmed quantities during sales order change. This means that for new orders to get confirmed, the sum of the receipts has to be more than the sum of the requirement quantities.

Response This setting works only if you have value 1, 2, or 3 maintained in the Accumulation field for your checking group. When you are processing an availability check using accumulation and there is a material shortage, this indicator helps control whether to issue an output (a dialog box with shortage information) to the user indicating the shortage. Available values are 0 and 1. Select 0, or leave the field blank, if you want no system response on a shortfall. Select 1 if you want a system response on a shortfall.

RelChkPlan This indicator is relevant only if you are setting up the availability check against planning (in other words, planned independent requirements, which is out of the scope of this book).

To create your own checking group, click the New Entries button on the menu bar and provide up to a two-character identification key with a meaningful description. Make the necessary selection for the customization fields shown in Figure 6-12 to match your business requirement, and save your entry by clicking the Save button. For Galaxy, we created a new checking group called Z9 with an individual requirement and confirmed quantity blocking, as shown in Figure 6-14.

Step 6: Define Scope of Availability Check

Once you have defined the checking group, the next step is to define the scope of the availability check. A combination of checking group and checking rule controls the scope of an availability check. SAP’s SD application predefines checking rules. You use checking rule A for sales orders and B for deliveries. Figure 6-15 shows the customization screen for defining the scope of an availability check. You can reach the customization screen using transaction OVZ9 or by following menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer Of Requirements ⇒ Availability Check ⇒ Availability Check With ATP Logic ⇒ Carry Out Control For Availability Check.

Let’s take a look at the relevant fields available on this customization screen:

Stocks By default, the availability check in SD is carried out by considering the unrestricted stock available at the delivering plant/warehouse. This section of the customization screen allows you to include other stock, namely, safety stock, stock in transit, quality inspection stock, blocked stock, restricted use batch stock, and subcontractor stock, in the availability check calculations. By selecting the relevant check boxes on this tab, you can include these special stock situations in the availability check.

Replenishment Lead Time This tab allows you to include or exclude RLT in your availability check calculations. Select Check Without RLT if you want to exclude RLT; leave it deselected if you want to include RLT. The consignment process in the SD application is one example of a scenario that does not require RLT.

In/Outward Movements By making a selection in this part of the screen, you can include or exclude the material receipts and issues from various document types in your availability check calculations. As you can see from the customization screen shown in Figure 6-15, you can include the purchase order, purchase requisitions, reservations, deliveries, sales requirements, and so on. When checked, both inward and outward movement of the selected entry will be included in the availability check logic.

Storage Location Inspection The No Storage Location Inspection field, when selected, switches off the availability check at the storage location.

Missing Parts Processing When a goods receipt posting is made in the Inventory Management application of SAP, the value you enter in the Checking Period: GR field helps determine the number of days that the system should look into the future to check for missing parts.

The value you enter here helps in initiating the workflow in the SAP system to trigger an email to the MRP controller, if the goods receipt is carried out in Inventory Management for the missing part. Maintain the value in this field for the combination of the checking group and the checking rule you are setting up only when you want to carry out the missing parts processing in Inventory Management.

Receipt In Past This field controls whether the sales order can consume the stock from receipts only in the future or from both the past and the future. Leave the field blank for including receipts from the past and future, choose A to do the same as leaving it blank but with a message, choose B to consume only future receipts, and choose C to perform the same as B but with a message.

To create your own scope, define the scope for a combination of the checking group and the applicable checking rule (A or B). Use the New Entries button to maintain the entry. Make the desired selections as per your business requirements, and save your entry.

Further Fine-Tuning in Customizing

In addition to the six steps of customization we just discussed, the SAP system also provides you with customization options to further fine-tune the availability check and transfer of requirements functionalities. Let’s look at these customization options.

Defining the Checking Group Default Value

The checking group is assigned to the material master record in the Sales: General/Plant view. When you create a material master record, you can either enter the checking group manually or have the system use a default value based on the customization settings done here in transaction code OVZ3. The menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer Of Requirements ⇒ Availability Check ⇒ Availability Check With ATP Logic ⇒ Define Checking Group Default Value.

To define your checking group defaulting rule, click the button, and enter the material type and plant combination for which you want to default the checking group into the Material Type and Plant fields on the screen. Enter the checking group in the Availability Check field corresponding to your material type and plant field, and click the button to save your entry. To help you visualize the setup, Figure 6-16 shows the customization setup for Galaxy Musical Instruments, where we have assigned checking group Z9 to material type HAWA and plant 9001.

Defining the Default Availability Check Rule per Sales Area

This customization is really important because this controls the end result for the availability check run. The customization choices you make here will decide whether the system will perform an availability check as if the delivery is a one-time, complete delivery or whether it’s a partial delivery; whether the SAP system shows a dialog box to the user when there is a shortage of stock; and how the system will behave while running the availability check in background mode. The determination rule here is set up by sales area. The transaction code is OVZJ, and the menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer of Requirements ⇒ Availability Check ⇒ Availability Check With ATP Logic ⇒ Define Default Settings. Figure 6-17 shows the customization screen for this setup.

As you can see, the screen consists of five columns. The first three columns on the screen, taken together, represent the determination key, that is, the sales area for which you want the availability check defaults to be maintained. Here is what the other two fields do:

Fixed Date And Qty Select this check box if you have a business requirement to default this field for a sales area. This field fixes the delivery date and quantity in a customer order and indicates the customer’s confirmation of the delivery date proposed by the availability check run. In a scenario where the customer accepts delivery in full only and the availability check can only confirm a delivery date later than the customer requested date, marking this check box in the sales order schedule line or on the availability check overview screen confirms the customer’s response to the delivery proposal suggested by the availability check run. If the customer agrees to accept delivery on a later date, you select the check box, and the requirements are transferred to MRP with the fixed delivery date and fixed quantity. The current available stock is not consumed by the order, and it becomes the job of the MRP department to meet the delivery deadlines as per the Fixed Date And Qty value transferred to MRP from the sales order.

Always remember that selecting this check box in a sales order also excludes the sales order from all subsequent order backlog processing and rescheduling job runs. This means that even if the goods do become available prior to the fixed date, you cannot allocate them to the order and therefore cannot ship prior to the fixed delivery date maintained in the order. To allocate them to this order, you need to deselect the Fixed Date And Qty field in the order document before you carry out the availability check processing. Therefore, to include orders in backlog processing and rescheduling, do not mark this field in scenarios where the customer accepts partial deliveries and wants deliveries to be made as early as possible.

Avail. Check Rule In the case of a stock shortage, the SAP system generally brings up the availability check overview screen, asking the user to make a selection out of the delivery proposals that resulted from the availability check run. Using this field, you can control this system behavior by sales area and can force the SAP system to go with the proposal set up here in customizing instead of taking user inputs. You can select A for the system to automatically choose a one-time delivery proposal, B for full delivery, and C for the system to propose partial delivery proposals. Options D and E act just like A and C, respectively, when processing happens in background mode, but they provide a dialog box for user inputs when processing happens in foreground mode. Leaving this field blank brings up the dialog box in foreground mode and treats the proposal as a full delivery only in background mode. Select 1 if you want a delivery proposal from the product selection.

To maintain your rules, select the required sales area for which you want to maintain the availability check default rules, and make necessary selections in the Fixed Date And Qty and Avail. Check Rule fields based on your business requirements. Save your entry when finished with the setup process.

Defining the Material Block for Other Users

Unlike the soft block indicator (the Block Qt.Rq. check box) available in OVZ2 that only blocks a confirmed quantity and allows users to carry out an availability check simultaneously for the same material/plant, the material block functionality available in OVZ1 puts an exclusive (“hard”) block on the material/plant, thereby restricting other users from simultaneously carrying out an availability check on the material/plant combination. The block is defined for a combination of the checking group and transaction (sales order or delivery) in customizing. The block is set when the availability check is carried out for the transaction document in create/change mode and is released when the document blocking the material/plant is saved. If both blocks (OVZ1 and OVZ2) are active in customizing, the block set at OVZ2 takes precedence.

The menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer Of Requirements ⇒ Availability Check ⇒ Availability Check With ATP Logic ⇒ Define Material Block For Other Users. To set up a material hard block, select the required combination of the checking group and transaction, and select the corresponding Block check box. Leave the field deselected if you don’t want to set up a material block. Save your entry when finished with the setup process. As a reference, Figure 6-18 shows the material block customization screen for Galaxy Musical Instruments.

Creating a Block Quantity Confirmation in Delivery Block

A delivery block puts a stop on further processing for a sales order. Here, you can set up a delivery block to allow or disallow the quantity confirmation for a sales document. In addition, you can also set up a planned deferral of the quantity confirmation. This is really useful in situations where you don’t want the availability check to confirm the quantity of the order if the order is under a delivery block, such as in the case of orders failing credit checks. This allows the stock to be available for other orders that are not under a delivery block. The transaction code is OVZ7, and the menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer of Requirements ⇒ Transfer Of Requirements ⇒ Block Quantity Confirmation In Delivery Blocks. Figure 6-19 shows the customization screen for this activity.

Let’s look at the fields on the customization screen:

Dlv.Block and Delivery Block Desc. These fields represent the delivery block identifier and corresponding description. These fields are autofilled for this customization screen with the number of delivery blocks configured in your SAP ERP system.

Conf.Block This field controls quantity confirmation. Mark this check box if you want to block the quantity confirmation for a delivery block, and leave it unmarked if you don’t want the quantity confirmation to be blocked.

Def.Period This field allows you to put a planned deferral of quantity confirmation in a sales order. This is really useful for situations where you know the lead time required to complete all the necessary formalities in advance and you would like to defer the quantity confirmation until the end of the lead time. For example, let’s say today is the 9th and you get an order from a new customer today for requested delivery by the 12th. The material is available in sufficient quantities on the 6th and the processing time is three days, which means that the system can confirm the delivery by the 12th. Your organization needs four days of lead time to set up the terms account for the customer (which involves getting a credit history and setting up the credit limits, payment terms, and so on). If you set up the delivery block called New Customer for a quantity confirmation with four days deferral, the SAP system will consider these four days of lead time while confirming quantities in the sales order and will propose the 13th (the 9th + four days) as the confirmation date. Note that the system starts calculating the lead time for deferral from the current date.

To fine-tune your delivery blocks for quantity confirmations, choose the required delivery block, and make selections in the Confirmation block and/or Deferral fields. Save your entry when finished with the setup process.

Refer to Chapter 7 for more details on customizing and using delivery blocks in sales and delivery processing.

Maintaining a User-Defined Requirement for Availability Check and Transfer of Requirements

For further fine-tuning of your availability check processing, SAP also lets you define your own requirements. You can add a technical piece of code to further allow/disallow quantity confirmation based on your business requirements. You have seen the use of requirements in Chapter 5, “Pricing and Tax Determination.” Here also the requirements serve a similar purpose with respect to TOR and availability check calculations. SAP will execute your code only if the requirement is met.

You can use transaction VOFM followed by menu Requirements ⇒ Subsequent Functions ⇒ Reqs.Availability, or you can use the menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer Of Requirements ⇒ Transfer Of Requirements ⇒ Maintain Requirement For Transfer Of Requirements. The standard SAP system provides requirement type 101 as an example of a user-defined requirement that contains a technical code to set a confirmed quantity on a sales order at zero if the document is under a credit block status.

Determining the Procedure for Each Delivery Item Category

Once activated at the requirement class level, the availability check is valid for all delivery documents. But just like sales orders, not all delivery documents need an availability check. Return deliveries are a perfect example of when you don’t need an availability check to be carried out. This customization screen gives you detailed controls to handle such situations. Using customization settings available on this screen, you can switch off the availability check for a delivery document via the delivery item category control. The transaction is OVZK, and the menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer Of Requirements ⇒ Availability Check ⇒ Availability Check With ATP Logic ⇒ Determine Procedure For Each Delivery Item Category. Figure 6-20 shows the customization screen for this setup.

Here is an explanation of the three fields on this screen:

Item Category The ItCa field represents the item category for which you want to fine-tune the availability check operations.

Description The Description field shows the name of this item category. Both of these fields are autofilled by the system based on item categories configured in the system.

Avail. Check Off The field Avail. Check Off is the one you need to select if you want to switch off the availability check for an item category. If this field is left blank, it means the availability check is on. An X here means the availability check is off.

To switch off the availability check for your item categories, select the relevant item category, and choose X in the corresponding Avail. Check Off field. Leave the value in this field blank for the item categories on which you want to carry out an availability check. Save your entry when done with the setup.

Checking the Rule for Updating Backorders

Here you assign the checking rule for SD transactions (A for sales order and B for delivery) to a plant. This is required before you can process backorders. The transaction code is OMIH, and the menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Availability Check And Transfer Of Requirements ⇒ Availability Check ⇒ Availability Check With ATP Logic ⇒ Checking Rule For Updating Backorders. Figure 6-21 represents this customization setup for Galaxy Musical Instruments.

Working with the Availability Check

Now that we have covered the configuration setup, we’ll show how these configuration elements work together to perform the availability check and transfer of requirements. Figure 6-22 summarizes how the complete availability check/transfer of requirements functionality works in SAP.

As you can see, when you create a sales order, the item category from the sales order, together with the MRP type from the material master record, determines the requirement type. The requirement type determines the requirement class, which in turn tells whether the transfer of requirements and availability check are activated in customizing. The next check is performed at the order schedule line level to determine whether the sales order is relevant to carrying out the availability check and passing on the material requirement to MRP. When found relevant, the availability check is carried out by SAP, taking into consideration the scope of check determined using the checking group from the material master record and the checking rule from the sales transaction as the determination key. If the check is successful, quantities are confirmed on the schedule line. If unsuccessful, the shortages are transferred to MRP to plan for the procurement/production of goods.

Availability Check in Sales Order

In a sales order, the availability check is carried out for the delivering plant. Figure 6-23 shows the availability check overview screen that is automatically displayed by SAP if a shortage of stock is encountered during an availability check run in a sales order. You can also call this screen from a sales order’s create/change mode by clicking the button on the sales order screen.

Take a close look at the screen. You will see that the screen contains the information from the sales order for which the availability check was carried out (such as plant, requested quantity and date, material number, and so on), and the bottom segment of screen represents the various proposals generated by the system as a result of the availability check.

As you can see, the customer ordered 192 units of material 1628 for a requested delivery date of 8/26/2009. After carrying out the availability check, the system found that only 84 units are available for delivery as of 8/26/2009. The system gave three proposals:

• Proposal 1: If customer wants only a one-time delivery, only 84 units can be delivered by the customer requested delivery date of 8/26/2009.
• Proposal 2: If customer wants only a complete delivery, all 192 units can be confirmed for delivery by 8/28/2009 (that is, the end of replenishment lead time).
• Proposal 3: If customer agrees to a partial delivery, 84 units can be delivered by 8/26/2009, and the balance (108) can be confirmed by the end of the replenishment lead time, in other words, 8/28/2009.

To choose a proposal, you can either click the button next to the proposal you want or click the respective buttons for the proposal that you want to choose from the menu buttons. Click to select complete delivery, to select a one-time delivery, and to select a delivery proposal with partial quantities.

You can perform an availability check on a plant other than 9001 by clicking the button on the menu. The button will provide you with information about the ATP quantities. Click the button if you want to see what is included/excluded by the system while carrying out the availability check. You can also call this overview screen from outside a sales order using transaction code CO09. Figures 6-24 and 6-25 represent the selection and output screens for CO09: Availability Overview.

Table 6-1 describes the commonly used transactions for checking the stock availability in the SAP system.

Table 6-1: Transactions to Check Stock Availability

Transaction Code	SAP Easy Access Menu Path	Title and Description
MB53	Logistics ⇒ Materials Management ⇒ Inventory Management ⇒ Environment ⇒ Stock ⇒ Plant Stock Availability	Display Stock Availability: Provides a detailed report on the stock availability in a plant.
CO09	Logistics ⇒ Materials Management ⇒ Inventory Management ⇒ Environment ⇒ Stock ⇒ Availability Overview	Availability Overview: Provides the availability overview for a material/plant combination.
MD04	Logistics ⇒ Materials Management ⇒ Inventory Management ⇒ Environment ⇒ Stock ⇒ Stock/Requirement List	Display Stock/Requirements Situation: Displays the current stock and requirements situation for a plant and material combination. This report provides a more detailed picture of the stock availability than does CO09.

Availability Check in Shipping

An availability check at delivery is required because of the dynamic nature of the availability check process and the elements that comprise the check. You should know by now that an availability check is performed based on the current stock in hand plus a planned inward and planned outward movement of goods. A planned future movement is always subject to change because changes in underlying factors can also affect the stock situation in the delivering plant. For example, a stock situation that existed during the sales order confirmation may not exist anymore during delivery. There are countless factors that can contribute to such situations—a planned future receipt coming later than expected or coming way before, lost output in production, release of confirmed stock from stock reservations to unrestricted stock, consignment stock picked up from customer location, a sudden or increased consumption of the finished goods by assembly orders because of an increase in demand for a kit or combo sale, cancellation of an already confirmed order, confirmed orders put on credit hold...these are several real-world examples of factors that consume or release stock and can change the stock situation in the delivering plant or warehouse between the order confirmation and delivery time. Stock transfers are the biggest contributor to such situations because they have the ability to steal stock from plant A and provide it to plant B, jeopardizing all the delivery schedules for plant A. Even a change in production capacity or warehouse capacity to process orders can bring a change in the availability check results. An availability check at delivery is, therefore, a must.

When you create a delivery, an availability check is initiated for the picking date along the same lines as sales orders. If the stock is not available at all, the system enters a delivery quantity of zero. You can process a delivery with a zero quantity only if it is permitted in delivery customization. If the quantity available is less than the order quantity requested and customer agrees to a partial delivery, then the available quantity is taken as the delivery quantity in the delivery document, and a corresponding reduction is made in the order quantity.

Backorder Processing

A backorder is an order stage that represents the orders for which an availability check is not able to find the sufficient quantities or no stock at all to confirm the customer-requested delivery date. When the stock situation changes in the delivering plant/warehouse, you can run the transaction for backorder processing to process these unconfirmed orders for confirmation. While processing backorders, you can assign the newly available stock (ATP quantities) to unconfirmed orders. You can also adjust the stock by releasing it from an existing confirmed order and assigning it to another unconfirmed order manually. In the SAP system, you can run transaction V.15 to generate the list of backorders that exist in the system followed by transaction CO06 to process them manually. Alternatively, you can use transaction V_RA, which provides you with both the list and the screen used to process backorders. To explain backorder processing, we will use transaction V_RA.

Backorder Processing Using a Selection List

Figure 6-26 represents the selection screen for processing backorders using a selection list. Based on the choices you make on this selection screen, the SAP system will generate the list of backorders for processing, as shown in Figure 6-27.

To process backorders, select the required documents, and click the Backorders button on the menu. Or use Edit ⇒ Backorders to call up the backorder processing overview screen, as shown in Figure 6-28. If the stock is available, it will be shown in the Cumul. ATP Qty field. To adjust the stock confirmation for an order, double-click the required MRP element, and enter the new committed quantity in the Committed field in the Sales Requirements section at the bottom of the screen.

Rescheduling a Sales Document

The standard availability check allocates stock based on a first-come, first-served basis. In other words, the orders entered first in the system will be confirmed first. In practice, this is not always what you want. Sometimes you want the goods to be assigned to an order that came in last. A common example of such situations is consumption of available stock by a low-priority order that pushes a high-priority order into backorder status because the low-priority order was entered first into the SAP system. Rescheduling is handy in such situations, allowing you to release the quantity blocked by the low-priority confirmed order and reassign the same to the high-priority order so as to meet the delivery schedule for the high-priority customer. You can perform rescheduling using transaction code V_V2 or using the SAP Easy Access menu path Logistics ⇒ Sales And Distribution ⇒ Sales ⇒ Backorders ⇒ Rescheduling ⇒ Execute. Figure 6-29 shows the selection screen for rescheduling a run.

The screen is divided into three sections:

Data This section of the screen allows you to enter the material and plant for which you want to run the rescheduling.

Options This section of the screen allows you to further fine-tune your selection for the rescheduling run.

Process Sales Documents Select Process Sales Documents to include all the open sales documents (for the material and plant combination specified in the data section) in the rescheduling run.

Process Stock Transfer Docs Select Process Stock Transfer Docs to include stock transfer orders, stock transfer scheduling agreements, and purchase order requests in the rescheduling run. You can include these stock transfer documents as an item-level selection or schedule line–level selection. Always remember that schedule line selection takes more processing time than item-level selection.

Unconfirmed Documents Required Select the Unconfirmed Documents Required check box to include the backorders into the rescheduling run.

Simulation Select the Simulation check box to run the rescheduling in test run mode without making any changes to the selected orders. You can also run transaction code V_R2 to run the rescheduling evaluation separately. The menu path for this is Logistics ⇒ Sales And Distribution ⇒ Sales ⇒ Backorders ⇒ Rescheduling ⇒ Evaluate.

Sort Order This section of the screen allows you to set the prioritization for the rescheduling run and also to set the sorting order for the rescheduling output. A maximum of five priority levels are allowed. The system will read the documents and process the rescheduling run based on these priorities.

Figure 6-30 and Figure 6-31 show an example of how priority can affect the end result of a rescheduling run. In Figure 6-30, customer 10014 is a low-priority customer who got all the stock allocated as order 12228, which was entered prior to order 12339 (a high-priority customer order) and 12240 (a next-day shipment order) [see prev.confirmed qty field in Figure 6-30]. Later, a stock of 70 units came as inward movement, raising the ATP stock availability in delivery plant 9001 for material 1628 to 70 units. When the rescheduling run is executed with the selection criteria shown in Figure 6-29, the SAP system will select all the undelivered confirmed and unconfirmed orders for plant 9001 and material 1628 and start allocating them on the basis of delivery priority (priority 1 is to select an order, and priority 2 is to allocate inventory based on the delivery priority). Thus, order 12240 (being the next-day shipment order) gets fully confirmed for 70 units from the available ATP stock. On the other hand, 25 units were released from low-priority order 12228 and got reassigned to high-priority order 12239, thus completely confirming order 12239 too [see new confirmed qty field in Figure 6-30].

If you reshuffle priority 2 and priority 3 on the selection screen (Figure 6-29) the whole calculation for rescheduling changes, as shown in Figure 6-31. Because Earliest Delivery Date became priority 2 and Delivery Priority became priority 3, order 12228 still gets to keep its old confirmation for 220 quantities, and the available ATP stock of 70 got assigned to the next-day shipment order 12240. The high-priority order 12239 remains without confirmation.

Figure 6-31: Log screen for rescheduling test run after reshuffling of priorities

It is always advised to run rescheduling in background mode, because it is a performance-hungry transaction. Also, make sure that when you run the rescheduling transaction, there is minimal order-related activity in the system. Keeping an order open in change mode while rescheduling is running can lead to an order document being skipped from the run and in rare cases can lead to wrong allocation or duplicate allocation of stock.

Summary

In this chapter, we explained the customization steps for setting up the availability check and discussed the importance of an availability check in the overall processing of a sales transaction. During this discussion, we also covered two related functionalities—transfer of requirements and backorder processing—in detail. In next chapter, we will discuss sales document types and related customization.