what is availbilty check? and its purpose?

[Former Member]

what is availbilty check? and its purpose?

[Former Member]

Dear Deva,

A small search on SDN SD forum will help you to answer your query.

I will suggest you to visit http://sap-img.com/sap-sd.htm. It will give you the overview of SAP SD module.

Moreover there is a separate section of FAQs with answers which will help you in great deal.

Hope this helps you.

Do award points if you found them useful.

Regards,

Rakesh

[Former Member]

Availability check is what the Moderators of this forum should be doing for you. - Limiting your availability to ask basic questions which you can easily find the answers to outside of this forum.

Please do so before asking here.

[Former Member]

hi,

To confirm the quantities for a particular line item in the sales order on particular day system carried out transfer of requirements (TOR) & AVAILABILITY check, so has to confirm the quantity on particular day as system should know what are there requirement of the sale order and delivery with MRP then system carries out availability check function, to confirm the quantity on particular day. Depending upon the IMG setting system carries out availability check function based on 3 methods:

A) Availability Check with ATP logic or against planning:

In ATP logic systems ATP Qty while carrying out availability check function for

Particular line item (ATP qty=warehouse stock +planned receipts planned issues)

Planned Receipts: EX: - purchase requisitions, purchase orders, stock in transfer stock at inspection etc.

Planned Issues: - EX: - open sales order & open delivers

B) Availability check against product allocation:

Availability check can be carried out against product allocations in which system automatically restrict the user to confirm the quantity beyond reserved quantities per particular customer. EX:- Availability qty =100, existing orders=10,then system automatically distributes to items evenly to the sales order.

C) Rule based Availability check:

Rule based availability check can be carried out based on the business transaction.

EX: - For normal sales order system has to carry out availability check for special sales order ex: - cash sales and rush order systems need not to be carry out availability check,

In rule based availability check system in which system carried out Global availability to promise in all plants. In this check system transfers the requirements to APO system where GATP takes place and the result of the availability check transferred to R/3 system. This process takes place with the transaction code CIF(central inter face) inR/3.After carrying out availability check function system proposes(by using ATP logic) default values of ATP check result to the user in a dialog box, in which system gives the choice to the user to take the decision in contest of insufficient stock.

a) One time delivery:

If the user chooses one time delivery and the order Quantity is 100 units system confirms 50 units then systems automatically confirms as a zero. If the user saves the document with the zero confirm qty then system trace the sales order as aback order (V_RA), which can be confirmed later by RESCHEDULLING (V_V2).

b) Complete Delivery:

If order Qty=100, Availability stock = 50, system says that remaining can be given after one week. Then if the user selects this option then system push up existing confirmed qty to after one week and the total qty can be confirmed after one week only.

c) Delivery Proposal:

If order qty=100, system confirms 50, and remaining 50 can be confirmed after one week. If the user chooses this option then system confirms 50 Qty today allows the user to delivery 50 quantities today remaining 50 can be delivered after one week.

CONFIGURATION SETTINGS FOR TOR:

Define Requirement Class:

Path: Img  S&D  Basic functions  Availability Check & Transfer of requirements  Transfer of requirements  Define Requirement classes

Requirement classes control MRP, Requirement consumption, strategy, relevance for planned. It specifics whether the availability check & TOR to be Called out for transactions. Ex: Sales Order

It determines whether requirements relevant for MRP or not, the allocation indicator from the sales view which controls the settlement of customers requirements with planned independent requirements. It determines the item b to be settled as an availability heck. Assignment, the settlement profiles the results analysis key. The TOR and Availability check functions are globally controlled using the requirement class for all the Sales documents. The values from the Requirements class are transferred to scheduled the of the sales documents class are transferred to scheduled the of the sales document default values and can be over written there.

Define Requirements Classes:

Requirement class defines whether the system has to carry out availability check based on the STP Qty. Ex:

Define Requirement Types:

Here we define requirement type, Ex: and Assign to Requirement class that we defined in the promote step.

Determination of Requirement types using Transaction:

Requirement type is going to be determined for sales document by following a search strategy. .

First System checks strategy group in MRP3 view if it trend requirement type then system takes from it, otherwise.

It will go to MRP group in MRP1 view, otherwise

It will check to Material type, otherwise

It will go to item Category + MRP type, otherwise

It will go to Item category only, otherwise

Finally system determines the transaction b not relevant for TOR & Availability check.

Choose Item category TAN+MRP type PD=Requirement type =0

Define Procedure for each schedule the category:

Here we define respective schedule the category of the sales documents, whether an availability check and TOR should be carried out. This setting is relevant for sales documents only. It is fine tuning of availability check for sales documents TOR & Availability check function can be activated at sales order level those are proposed in to schedule line category level. If u wants to deactivate TOR availability check function at schedule the category level and want to deactivate at requirement class level it b impossible.

Ex: If u wants to check availability w/o transferring the requirement we can use it.

Choose schedule line category CP & Activate Availability check, requirement & Product Allocation

Block Quantity confirmation in delivery Blocks:-

When we transfer requirements to MRP then confirmed quantities is also reserved for confirmed sales documents, if transaction is blocked for delivery the reserved quantities are also blocked so that the conformed quantities cannot be used by any other purpose. So has to avoid this situation we can block the transfer of requirements(TOR) for delivery blocks, in this case requirements transferred to MRP but will not be reserved, that will be cleared once we save the documents then system shows confirmed qty as zero.

When we remove the delivery block then system automatically carries out availability check & confirms the qty.

A) Deliveries: Blocking region for sales Area:

Here we define blocking regions for TOR ex:-credit limits

B) Reasons for scope of delivery blocks: TOR. Block:

Ex: - 01 credit limits-check confirmation block.

Maintain Requirements for TOR:-

Here we can define our own requirement with the help of ABAPer for TOR

Ex: - a) 102- prevent reservation in the event of credit block

b) 102-purchase requisitions.

System doesn’t create purchase requisitions for sales order line items if it has a credit limit.

Availability check:

Configuration setting:-

Availability check with ATP logic or against planning:-

Define checking group:

Checking group define what kind of requirement record system use to create when sales order & deliveries are processed for this material. We can create 2 kinds of requirements records

Individual requirement records: that means system creates requirement record for each S&D document.

Summarized requirement Records: That means system creates requirement records under certain condition in the material master record. There are 2 type of summarized requirement record:

Summarized requirement records for each day.

Summarized requirement records for each week

Define checking Action;

Here we define 01- daily requirement -B 02- Individual requirements -A

Where b-total record per day

A-single record per day

B) Define material Block for other users:

When 2 users tries to confirm the quantities for the sales order for same material at a time system will be confused to confirm the quantities both sales orders. So has to avoid this kind of situation we can block the materials from confirming the quantities for 2 users at a check, check block

C) Define checking group default values:

Checking group is going to be determined depending upon the material type & plant.

-Go to new entries, specify material type, ex;-FERT

& plant = checking group of availability check: 02

D) Carry out for Availability check:

Here we define checking rule for the Availability check & allocate them to the checking group. The checking rules specify the scope of the availability check. For a respective transaction, means which planned receipts & planned issues systems has to taken into consideration and also it determines whether system has to take RLT into consideration.

Action:

*Select checking group of availability check-02, checking rule=01

*Go to details icon, & check which planned receipts & planned issues system has taken into consideration for availability check

*save it, exit.

E) Define procedure by Requirement class:

Here we define requirement class whether on availability check & TOR should be carried out the setting that we carries out at requirement class level they are at global level. There settings automatically copied into define from of requirement class and vice versa.

Action:

*Choose requirement class: 041 & check availability check & TOR (requirement)

F) Define procedure for each schedule line category:

Here we carry out fine tuning setting for availability check at schedule line category level. Here we define whether system has to carry out Availability check for particular transaction.

Ex:- if we want to implement a availability check w/o TOR for a particular transaction. According to settings at requirement class level TOR & availability check function activate & those setting will be copied into the schedule time category by default, so that at schedule line category level we deactivated TOR

G) Determine procedure for each Delivery Item category:

Here we switch on or switch off availability check functions of a delivery item category

*choose item category ‘TAN’. & specify the appropriate value.

H) Checking group for updating back orders:

Here we assign checking group to a plant that rule specifies for individual application, according to which the availability check is carried out;

I) Define Default settings:

Here we define the result of the availability check.

*Choose your sales Area, & check fixed dates& Qty options & specify ‘D’ or ‘E’

Where: D- Dialog box in the case of shortages (one time delivery)

E- Dialog box in the shortages (delivery proposal).

with regards

Ram

[Former Member]

Availability Check in Sales and Distribution Processing

There are three types of availability check:

• Check on the basis of the ATP quantities

• Check against product allocation

• Check against planning

In Customizing, you determine whether an availability check is to be carried out against the ATP quanitity or against planning. The check against product allocations is controlled in the material master and elsewhere in the system.

Check on the Basis of the ATP Quantities

The ATP quantity (ATP = Available To Promise) is calculated from the warehouse stock, the planned inward movements of stock (production orders, purchase orders, planned orders) and the planned outward movements of stock (sales orders, deliveries, reservations). This type of check is performed dynamically for each transaction, taking into account the relevant stock and planned goods movements with or without replenishment lead time. Planned independent requirements are not taken into account here.

Check against Product Allocation

Product allocation facilitates period-based distribution of products for certain customers or regions. As of Release 3.0F, you can carry out an availability check against product allocation. This ensures, for example, that when production is low, the first customer does not get the full amount, resulting in following sales orders not being confirmed or being confirmed far too late.

Check against planning

The check against planning is performed against independent requirements which are usually created for an ‘anonymous’ market rather than being customer-specific (for example, in the strategy ‘Planning without assembly’, when production occurs only up to the stocking level). The planned independent requirements result from demand program planning and are used for planning expected sales quantities independent of orders

Controlling the Availability Check in Sales and Distribution Processing

You control the availability check using general and SD-specific control features.

General Control Features

The following control elements need to be maintained in Customizing and in the material master record:

• Strategy group

The allowed planning strategies (main strategy and further possible strategies) are combined in the strategy group. As of Release 3.0, the strategy group is specified in the material master record in the MRP 1 Screen. In Customizing, strategy groups are assigned, dependent on plant, to MRP groups. If the strategy group is missing in the material master record, it is determined on the basis of the MRP group, if it has been maintained.

Up to Release 3.0, the strategy group is determined on the basis of the MRP group

• MRP group

The MRP group combines materials from the point of view of material requirements planning. This enables you to control planning for these materials in a particular way using, for example, the strategy group, consumption mode and planning period. You enter the MRP group in the material master in the MRP 1 screen. The strategy group is determined from the 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 Production Planning and Sales and Distribution.

• MRP type and item category

If no requirements type is found using the planning strategy, the system tries to determine a corresponding requirements type on the basis of the MRP type and the item category.

Until 3.0C, determination of the requirements type via planning strategy has taken priority. This is not always the best option, however, as the following example will show. A requirements type is determined for a material, which causes availability to be checked against planning. In consignment stock processing, however, availability should be checked against stock. Until 3.0C the availability check had to be deactivated in these cases. As of Release 3.0C, you can determine how the requirements type is to be determined for each transaction by maintaining the Source field in Determination of requirement types using transaction in Customizing.

• Requirements type

The various requirements are identified by their requirements type. The requirements type refers to the requirements class and its control features.

• Requirements Class

The requirements class contains all control features for planning such as relevance for planning, requirements planning strategy and requirements consumption strategy. In addition, it is specified at a global level whether an availability check is to take place for the material in the sales and distribution documents on the basis of the ATP quantity (ATP = available to promise) and whether requirements are to be passed on. A finer degree of control can be obtained for sales documents using the schedule line category.

Control Features Specific to Sales and Distribution

The following SD-specific control features need to be maintained in Customizing:

• Checking group

The checking group controls whether the system is to create indivdual or collective requirements in sales and shipping processing. In addition, a material block for the availability check with transfer of requirements can be set here. The checking group can also be used to deactivate the availability check. This option was created especially for the assembly order so that when the bill of material is exploded in the assembly order, the individual components, if necessary, can be classified as non-critical parts as far as procurement is concerned.

The checking group specifies in combination with the checking rule the scope of the availability check. It is proposed in the material master record on the basis of the material type and the plant, and copied into the sales and distribution documents.

• Checking Rule

You use the checking rule to control the scope of the availability check for each transaction in sales and distribution. You also specify whether the check should be carried out including or excluding replenishment lead time. The individual checking rules define by transaction, which stock and inward and outward movement of goods should be taken into account for the availability check.

• Schedule line category

You can control with the schedule line category whether an availability check and transfer of requirements should be carried out in the sales documents. The possible settings for this at schedule line level are dependent on the settings in the requirements class which is determined from the requirements type of the material.

• Delivery item category

The delivery item category can be used to control whether an availability check takes place in deliveries.

Prerequisites

An availability check can only be carried out if the following prerequisites have been fulfilled:

• The control elements described above for the availability check must be maintained in Customizing for Sales and the relevant assignments made to the sales transactions

• The availability check must be switched on at requirements class level and - for the availability check in the sales documents - at schedule line category level

• A requirements type must exist by which the requirements class can be found

• A plant must be defined. It can either be proposed from the customer or material master record or can be entered manually in the document.

• A checking group must be defined in the material master record on the Sales/plant data screen in the Availability check field

At the global requirements class level, the availability check can only be switched on in combination with the transfer of requirements. At schedule line level, the settings are proposed from the requirements class.

If the availability check is switched on at requirements class level, it can be switched off at schedule line level. However, you cannot switch on the availability check at schedule line level, if it is switched off at requirements class level. You can make this setting at schedule line level. But the system ignores it and the setting for the requirements class applies.

Also, at schedule line level when the availability check is switched on, the transfer of requirements can be switched off. For example, this makes sense for inquiries or sales information.

The settings specific to schedule lines for performing an availability check are only relevant for sales documents. In the shipping documents, the settings from the requirements 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.

Timing of the Availability Check in Sales and Distribution Processing

When you create an order, the system determines the required materail availability date on the basis of the customer’s requested delivery date. On this date, you must begin picking, packing, labeling, and loading the goods. Therefore, this is the date of significance for requirements planning on which the availability should be checked.

The following data is required for determining this date:

• Route from the shipping point to the ship-to party location

• Shipping point from which the goods are issued

• Loading group from the material master record

• Weight group determined from the order using the order quantity

Scheduling

This data, which you have already entered in the system, means that scheduling can occur automatically. Since scheduling is carried out backwards from the requested delivery date, it is also called backward scheduling. If backward scheduling determines that the preparation for the shipping activities should have been started already to meet the customer's requested delivery date, the system then starts forward scheduling automatically from the current date.

Scope of the Availability Check in Sales and Distribution Processing

The following elements can be included in the availability check:

• Stock

o safety stock

o stock in transfer

o quality inspection

o blocked stock

• Inward/Outward movement of goods

o purchase orders

o purchase requisitions

o planned orders

o production orders

o reservations

o dependent reservations

o dependent requirements

o sales requirements

o delivery requirements

Requirements in sales and distribution (sales requirements and delivery requirements) result from all transactions which forward a requirement to Materials Management (MM) or to Production Planning (PP). For example, this could include sales orders or deliveries and quotations as well. Sales and distribution requirements reduce existing stock or inward movements of stock on the material availability date to ensure that other outward movement of stock elements cannot access the quantity reserved in this way.

Requirements relevant for Sales and distribution are created in Sales and Distribution, whereas other elements in this list are created in Materials Management or in Production Planning.

Reactions to the Availability Check in Sales Documents

If the goods ordered by the customer are not available on the requested date, the system branches automatically during sales document processing to a further screen where delivery proposals are offered for selection. The system determines these proposals on the basis of the availability situation. This screen also provides you with information on the scope of the check, the current ATP quantity, and the availability situation across all plants.

Availability Control

On the Availability Control screen, you can choose between the following delivery proposals:

• One-time delivery on the requested delivery date

In this section, the system checks whether the requested delivery date can be kept to. If stock of the material is available to make a delivery on the requested delivery date, the stock quantity is confirmed here. If there is no stock available, confirmed quantity zero is displayed.

To copy this data into the sales document, select Edit One-time delivery.

• Complete delivery

In this section, the system checks whether there will be sufficient stock for complete delivery at a later date:

o If there is sufficient stock available at a later date to cover the required quantity in the sales document, the system proposes the date here.

o If the system determines that complete delivery cannot be made at a later date, no date is proposed in this section.

When availability is checked including replenishment lead time, the date which is proposed in this section is the date on which the replenishment lead time period ends if the stock before the end of replenishment lead time does not cover the order quantity.

When availability is checked excluding replenishment lead time, the system bases its calculations on the stock and the planned inward movements of stock.

To copy this data into the sales document, select Edit Complete delivery

• Delivery proposal

In this section, the system checks whether and for which dates partial deliveries can be made. Partial deliveries are displayed for different dates. These dates are based on the planned inward and outward movements of stock.

During an availability check which takes replenishment lead time into account, the date on which replenishment lead time ends is displayed if insufficient stock means that no partial deliveries can be made before replenishment lead time ends.

During an availability check which does not take replenishment lead time into account, the system displays the dates on which partial deliveries can be made with the available stock.

To copy this proposal into the sales document, select Edit Delivery proposal

Source: SAP library

Hope this helps.