Availablity check in SAP

1. TRANSFER OF
REQUIREMENTS AND
AVAILABLITY CHECK
CREATED BY
PANKAJ JAIN

2. TRANSFER OF REQUIREMENTS.
 During sales order creation, a line item in the sales order may create
a schedule line. The schedule line represents the customer’s
request delivery date and quantity to be delivered. This information
is transferred (TOR) to MRP. MRP is then able to determine if there
is enough quantity of stock available for the scheduled delivery date.
The TOR aims to ensure that materials ordered are ready for the
requested delivery date. The TOR is closely integrated with MM and
PP.
 To configure TOR-
IMG-> SD-> Basic function -> AC and TOR -> TOR
You are able to select for which documents you would like TOR
to happen. For example, you may not wish any TOR to happen for
quotations. However, you may want for standard sales order.

3. Individual or collective Requirements.
 TOR can be either Individual or collective requirement. This is set in
the AC field on the MM record in the sales: Gen/plant view. Not only
does this control how the AC is processed but also how the
requirements are transferred to MRP.
 Individual requirements takes each schedule line to MRP. An
advantage of this is that the availability overview [CO09] will show the
order quantity, sales doc no., item no. and requirement class for each
schedule line for which a demand has been created. The view of the
availability overview is configured using a checking group.
 Collective requirements are a collective grouping of requirements
created either daily or weekly and transferred to MRP. The documents
created in collective requirement processing cannot be individually
identified from the availability overview. Collective requirements are
useful to a business that deals with a large volume of sales orders per
day, as it allows the business to have a clearer view of the availability
overview as well as speeding up response time within the system.
The system will automatically create individual requirements for
materials with collective requirements indicated on MM record for
transaction that create special stock- consignment, returnable
packing, or make to order stock.

4. Transfer Of Requirements
 Requirements generated in Sales & Distribution need to
be transferred to material requirements planning to
ensure the quantities ordered are available to be
delivered on time to Customer. This is called transfer of
requirements (TOR).
 TOR are of two types:
 TOR with individual requirements
A line for each individual requirement is created in availability
overview for each sales document and schedule line. This helps
in tracking the initiating document. System uses this for special
stock scenarios like Make-to-order stock, project stock etc. It can
also be used for standard orders if sales order volume is not
large and requirements need to be tracked at item level.

5. Transfer Of Requirements
 TOR with collective requirements.
Collective requirements combine various requirements based on
following criteria:
 Plant
 Storage Location
 Batch
 Date
 Transaction &
 Requirement class
These requirements can either be created daily or weekly. The
documents initiating collective requirements cannot be directly
identified but can be traced via list of orders for material.

6. Control Elements in TOR - 1
 Control Elements of significance in TOR are
 Requirement type
 Requirement class
 Checking group
 Schedule Line category
 TOR needs to be switched on at Requirements class
and Schedule line category level for proper processing.
 Plant must be defined at item level in sales document.
 Checking group must be defined in material master in
Sales/plant view.

7. Control Elements in TOR -2
 The requirements class is the key factor in the TOR. It is
based on the requirement type for the sales doc. The
requirement type and, eventually requirements class are
determined in the strategy group so all changes made
there should also be coordinated through PP.
 The strategy group may be found on the MM MRP3 view
under planning.
 Settings for TOR specific to schedule line are only
relevant for sales doc. In the shipping doc, however, the
settings for requirements class apply.

8. CUSTOMISING FOR TOR
 Defining requirement class-
IMG—SD—BASIC FUNC—AC and TOR—TOR—Define RC.
The RC is the controlling factor for AC and TOR for all sales doc
types. The system uses the entries at RC level as default and brings
the data into sales order. The schedule line category is used to fine
tune the settings at RC level.
 Defining Requirement Type-
A RT is allocated to a single RC, however, a RC may be allocated to
many RT. RT is displayed in a sales order. It is based on the item
category and MRP type of the material. It is possible to change it
during sales order.
 Assign the RC to RT.
 Determination of RT using transaction.
IMG—SD—Basic Func—AC and TOR—TOR—Determination of RT
using transaction.
Assign RT to relevant item category in the sales order and MRP
type on the MM record.

9. CUSTOMISING FOR TOR -2
 There is a pre defined search strategy that the system uses to
determine the RT as follows :
1. First, an attempt is made to find a RT using the strategy group in
the material master.
2. Then if the strategy group has not been maintained, the system
will determine it using the MRP group.
3. If, however, the MRP group has not been defined, the system
uses the material type instead of the MRP group when accessing
the corresponding control tables.
4. If no requirement type is found, the system assumes a special
rule and attempts to find a RT by item category and the MRP type.
5. If this is not possible, a final attempt is made to find a RT with item
category only.
6. If the final attempt fails, the system declares the transaction as not
relevant for the AC or TOR.
If you do not want this to be followed but instead RT to be
found from Item category and MRP Type, then you may select an
alternative search strategy in the column next to the one where
you assign the RT. If you select 1, which determines that the
source is used as the item type and MRP type.

10. CUSTOMISING FOR TOR - 3
 Defining procedure for each schedule line category
IMG—SD—Basic function—AC and TOR—TOR—Define
procedure for each schedule line category.
Proceed with indicating which schedule line category will be
available for TOR or AC.
 Maintaining requirements for TOR.
IMG—SD—Basic function—AC and TOR—TOR—Maintain
requirements for TOR.
In the same way that requirements are used in access
sequences- that is, a number of preconditions must exist for
transaction to be carried out- requirements may also be used to
determine that TOR to MRP is not carried out unless a number of
conditions are met.
Requirements can also be set for purchase and assembly orders.
For example, requirement 101 stops a purchase or assembly order
from being created should a credit block exist on sales order.

11. TOR and CREDIT MANAGEMENT.
 The requested schedule line passes a requirement in spite of credit
management, credit control block, however the confirmation of the
requirement can be configured to be unconfirmed as in standard.
This requirement is also processed from the MRP run and the
procurement is triggered. The credit block does not stop this
process. The third party order processing and the assembly
processing is referred to as direct procurement. In both cases, the
procurement element is created directly from the sales order ( the
purchase requisition in case of third party order processing and the
production order, the planned order or the like in case of assembly
processing).
The credit block in the sales order prevents the creation of
procurement element. However if the credit block is first set during
change of a sales order, the procurement element is deleted again.
As long as credit block is set in the sales order, no procurement or
production occurs for this sales order.
If the sales order is released from the credit block, an AC is
carried out again for this order. The AC tries to confirm the
requested quantities.
In case of direct procurement, a purchase requisition or a
production order is created again in background.

12. CUSTOMISING TO BE MAINTAINED IN
MATERIAL MASTER RECORD.
 STRATEGY TYPE – in MRP1
 MRP GROUP – in MRP1 (strategy group is determined from MRP
group).
 PLANNING STRATEGY-
The planning strategy specifies the requirements type for
planning and customer requirements. This represents the decisive
control feature for the interaction between PP and SD.
 MRP TYPE and ITEM CATEGORY-
If no requirement type is found using the planning strategy, the
system tries to determine a corresponding requirements type on the
basis of MRP TYPE and the item category.
 REQUIREMENT TYPE
 REQUIREMENT CLASS-
At requirement class level, the availability check can only be
switched on in combination with the transfer of requirements (TR).
At schedule line level, the settings are proposed from requirement
class.

13. CUSTOMISING TO BE MAINTAINED IN
MATERIAL MASTER RECORD - 2
If the availability check is switched on at requirement class
level, it can be switched off at schedule line level.
Also, at schedule line level when the availability check is
switched on, TR can be off (e.g.. Inquires).
The settings specific to schedule lines for performing on
availability check are only relevant for sales doc. In the shipping
doc, the settings from requirement class and the delivery item
category are used. As with the schedule line category, the
availability check can be switched off as required in the delivery item
category.

14. Introduction of AVAILABILITY CHECK
 Availability check is one of the key functionalities in sales
document processing. The confirmation of delivery of
goods to customer while entering a sales document is
carried out on the basis of this check.
 Availability check can be carried out on the deadline of
goods availability that would be necessary to consider
the picking, packing and shipping time.
 Availability check can only be carried out if transfer of
requirements take place for goods from sales to
purchase or production.
 Availability check is carried out at a plant level.

15. Types of Availability Check -1
 System provides for three types of Availability check
explained as under:
 ATP basis check
Available To Promise (ATP) is calculated from warehouse stock,
planned inward movement of stock (purchase orders, planned
orders etc.) & planned outward movement of stock (sales orders,
deliveries, reservations etc.)
ATP check explained in equation terms above. The check is
performed dynamically for each transaction.
ATP W/h Stock Inward mvmt. Outward Mvmt.

16. Types of Availability Check -2
 Check against Product Allocation
Product allocation is used for period based distribution of
products for specified customers or regions. This check is over
the normal availability check. It is carried out in cases where
production is low and goods produced need to be distributed to
customers and ensured that first customer is not allocated
complete quantity.
 Check against Planning
Check against planning is performed against planned
independent requirements which are generated from a demand
planning program.

17. Replenishment Lead Time
 Definition: Replenishment Lead Time (RLT) is time that is
needed to order or produce requested material. RLT is
calculated based on time maintained in master data.
 ATP check Including RLT
 Availability check is calculated only up to end of RLT. If the
material availability date calculated on basis of current date lies
after RLT, system confirms the item in spite of insufficient stock
in the assumption that stock would be procured or produced by
that time. Thus confirmation can be sent to customer in this
case.
(refer example in next slide)

18. Replenishment Lead Time
Example: In this example (refer figure) 20 pcs of stock requested
by customer can be confirmed if RLT is included with ATP check
because although 20 pcs of stock may not be available on day
requested the date falls after the lead time specified for item and
hence stock would theoretically be available.

19. Replenishment Lead Time
 ATP check Excluding RLT
 If RLT is not included in ATP check system performs a check on
the unrestricted stock and scope of check on inward and
outward movement of stock.
Similar example as above excluding RLT check, system would
confirm the item only when stock would actually be available.

20. Control Parameters
 Control Parameters of Availability Check in Sales
Following SD specific control parameters need to be maintained.
 Checking Group
Checking group forms one of factors for specifying scope of availability
check. It is used for grouping of materials for individual or collective
requirements. It is assigned in material master Sales/Plant view.
Advantages of individual requirements-
1. Backorder processing is possible.
2. Access of order and line items and schedule lines in MD04. Thus
greater control over available stock and requirements.
Disadvantage is system performance.
The system automatically uses individual requirements for special stock
movements such as consignment stock, returnable packaging even if
summarized requirements have been selected.
 Checking Rule
Checking rule forms the other factor in specifying scope and is assigned
to each transaction in sales and distribution. The checking rules are
predefined in system.
The checking group plus the checking rule determine how availability
check is to be performed.

21. Control Parameters - 2
 Schedule Line Category
Schedule line category had additional check to turn on/off
availability check.
 Delivery item category
Setting in the item category can be used to check off availability
check in deliveries.
 Requirement class
It is possible to determine if an availability check is to be
performed for the material on the basis of ATP quantity and
whether the TOR is passed on.
 Requirement Type
The RC is assigned to RT in TOR.

22. TIMING OF AVAILABLITY CHECK
 When an order is created, the system determines the required
material availability date on the basis of the customer’s requested
delivery date. The following data is required for determining this
date-
- Route from the shipping point to the ship to party location.
- Shipping Point from which goods are issued.
- Loading group from MM record.
- Weight group from order using order quantity.

23. Process Flow
 The process flow in which system checks for Availability
is as follows Requirement Type exists to find
Requirement Class
Requirement Class has
Availability Check ON
Schedule Line Category has
Availability Check ON
From Material Master of Item
CHECKING GROUP
From Transaction (like SD
Order)
CHECKING RULE
AVAILABILITY CHECK

24. CONFIGURATION-1
 Defining checking groups
IMG—SD—Basic function—AC and TOR—AC with ATP logic
against planning—Define checking group.
The columns total sales and total deliveries are selection
options whereby you may configure a checking rule to sum up
requirements to post to MRP either individually or by day or week.
Block quantity requirement- check this setting if you want
several users to e able to process the material simultaneously in
different transaction without blocking each other.
The No check setting is used when you want a material not to
be relevant for an ATP check, thus no check is carried out for the
material with a checking rule indicating no check. E.g.. Material with
high quantity of stock.
 Defining material block for other users.
IMG—SD—Basic function—AC—AC with ATP logic or against
planning—Define material block for other users.
It allows to block the particular material from being checked for
availability if it is already being checked for availability at same time
by another user.

25. CONFIGURATION-2
 IMG—SD—Basic function—AC and TOR—AC—AC with ATP logic—
carry out control for AC.
 Following elements can be included in scope of availability check
 Stock
 Safety Stock
 Stock in Transfer
 Blocked Stock
 Quality Inspection
Inward/Outward movement of goods
 Purchase requisitions & orders
 Planned & Production orders
 Reservations
 Sales & Delivery requirements
 Dependent requirement
 Defining procedure for each delivery item category
IMG—SD—Basic function—AC and TOR—AC with ATP logic–
Determine procedure for each item category.
Availability check can be switched off at delivery item category here.

26. CONFIGURATION-3
 A checking rule is assigned to each transaction. This rule in
combination with the checking group controls the scope of
availability check. You can use the checking rules in customizing for
sales to specify for various transaction which of the elements listed
should be included in availability check.
Using the userexit_plant_selection in the include RVOZVFZZ,
you can make a preselection of the allowed plants.
The availability check is calculated using the planned inward
and outward movement of goods.
When you create the delivery for a sales order, the sales order
requirement is reduced by the delivery quantity. A delivery
requirement which is transferred to MRP is created at the same
time. You can define whether delivery requirements are managed as
individual or collected requirements.
The same control elements are used for carrying out the
availability check in deliveries as in availability check in sales doc.
The availability check in delivery is dependent upon the requirement
class which itself is linked to requirement type of material. In
addition, delivery item category can be used to control whether an
availability check is performed in delivery.

27. IMPORTANT TRANSCATIONS CODE
 Availability overview screen – CO09.
 Stock requirements list – MD04.
 Stock overview – MMBE.
 Plant stock availability – MB53.
 Warehouse stock – MB52.
 Expiration date list – MB5M.
 Stock for posting date – MB58.
 Stock in transit – MB5T.