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. 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.
Customization steps for availability check and transfer of requirements
• Activate Transfer of Requirements and Availability Check
Step 1 at Requirement Class Level
• Define Requirement Type and Assign Requirement Class
Step 2 to Requirement Type
• Set Up Determination Rule for TOR
Step 3
• Activate Transfer of Requirement and Availability Check at
Step 4 Schedule Line Category Level
• Define Checking Group
Step 5
• Define Scope of Availability Check
Step 6
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. 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 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.
Overview and detail customization screens for setting up the requirement class
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.the customization settings for requirement type 041 and its assignment to requirement class 041.
Defining a requirement type
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, 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.
CASE STUDY Galaxy Mus ical Instrum ents Configu ration Analys is: Requirement Class Ac tivation and Requirement Ty pe Setup
Galaxy Musical Instruments did not need to go for a new setup; instead, Galaxy decided to go with the standard SAP setup of requirement class 041 and requirement type 041 for carrying out the availability check and TOR.
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.
shows the customization screen for the rules setup.
rules for the requirement type determination using transactions 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.
CASE STUDY Galaxy Mus ical Instrum ents Configu ration Analys is: Requirement Ty pe Determination
In the Galaxy Musical Instruments setup, all the item categories that required an availability check and transfer of requirements, such as standard item (TAN) and free of charge item (TANN), were assigned to requirement type 041, whereas item categories for return orders (REN) and consignment returns (KRN) were excluded and were not set up for the requirement type determination.
Requirement Ty pe Determination in Standard SAP
Requirement type determination in standard SAP is performed using a six-level hierarchical sequence:
-
First, SAP tries to determine the requirement type using the strategy group from the material master record.
-
If the strategy group is not maintained, SAP determines the requirement type using the MRP group from the material master record.
-
If this is not maintained either, the SAP system determines the requirement type using the material type from the material master record.
-
If this also fails, the SAP system determines the requirement type using a combination of the item category and MRP type.
-
If this rule is not maintained, the SAP system at last tries to determine the requirement type using the item category itself.
-
If no requirement type is found at this level, the system treats the transaction as not relevant for the transfer of requirements or availability check.
If you do not want to use the hierarchical sequence provided by SAP and instead want the system to determine the requirement type based on, say, the item category and MRP type, you can select an alternative search strategy. This alternative search strategy has to be entered in column Qagainst the particular Item category and MRP type combination.
For assigning a search strategy in field Q, apart from the default option 0, SAP provides two more search strategy options: 1 and 2. Option 1 helps in determining the requirement type based on a combination of the item category and the MRP type. Option 2 is similar to 1 except that it also considers the allowed requirement types for this combination.
Step 4: Activate Transfer of Requirement and Availability
Check at Schedule Line Category LevelThis 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.
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.schedule line category level activation of TOR and availability check You can also activate the availability check and transfer of requirements using the schedule line category maintenance transaction VOV6.
CASE STUDY Galaxy Mus ical Instrum ents Configu ration Analys is: Ac tivation at the Schedul e Line Level
Galaxy Musical Instruments decided not to go for a new setup and instead to go with the standard SAP setup of the schedule line categories CP and CN for use with sales documents. Schedule line category CP is available in standard SAP for use with scenarios that use MRP, and CN is available for scenarios not requiring MRP. CP has both the requirement transfer and availability check fields selected, but CN contains no selection for these fields. As a result, sales documents using CP are eligible for transferring demand and carrying out the availability check, while the documents using CN aren’t.
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 achecking 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. the customization screen for defining a checking group. The entries in columns Av and Description show the checking group being configured and its description.
Defining a checking group
Lets quickly go through the other fields available on this customization screen:
Total Sales Requirements The field shown as TotalSales 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 TotDlvReqs 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.you cumulate the confirmed quantities. Without accumulation, there is a chance that SAP will confirm more quantities to orders than are available to promise. 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:
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 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 sumof 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.
Example showing inconsistencies in ATP calculations when accumulation is not used
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 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
Checking group customization screen showing checking groups defined for Galaxy Musical Instruments
CASE STUDY Galaxy Mus ical Instrum ents Configu ration Analys is: Checking Group
Galaxy wanted to transfer daily requirements for a few materials, individual requirement for a few others, and no requirement transfer for some materials. Therefore, we configured checking group Z9 for an individual requirement transfer with accumulation and Z8 for a daily requirement transfer with accumulation and then used SAP’s existing checking group KP for no availability check.
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.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.
Defining the scope of an 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, 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 Bbut 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,the customization setup for Galaxy Musical Instruments, where we have assigned checking group Z9 to material type HAWA and plant 9001.
Defining the checking group default value
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 onetime, 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. the customization screen for this setup.
Defining default settings for the availability check by sales area
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 the material block customization screen for Galaxy Musical Instruments.
Defining the material block for other users
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.
Blocking quantity confirmation in delivery blocks
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.
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. WARNING When defining your own requirement, use ABAP help, and rigorously follow the naming convention for the customer namespace. Not following the SAP customer namespace rules puts your SAP ERP instance’s code at risk of being overwritten by SAP code during SAP ERP oftware upgrades.
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. the customization screen for this setup.
Determining the procedure for each delivery item category
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. customization setup for Galaxy Musical Instruments.
Checking the rule for updating backorders
