availability check with product allocation configuration

[Former Member]

good morning

kindly give me the configuration details of availability check with product allocation configuration,

thank u

[former_member227476 · Accepted solution]

dear abdul

TOR AND AVAILANBILITY CHECK

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

reward if it helps

siva

[Former Member]

<b>ATP stands for available to promise.</b>

means: it is a functionaly in SAP that controls the availability of the sales stock.

for example, if you process a material thinking that it is available (when in reality not enough stocks are available) but when it comes to delivery u may not have sufficient quantity, then it becomes a problem for you to answer the customer since you are not able to meet up the delivery schedule.

thus to avoid this confusion during delviery, SAP has developed this control of checking the stock availabilty first before u confirm a Sale order to customer.

A precise planning and controlling mechanism is of the utmost importance for the execution of competitive order processing with guaranteed efficient and timely delivery to the customer of the required order quantity. Unforseen problems, such as production deficits or increased demand can have critical consequences for order processing and must be brought under control as soon as possible.

<b>Product allocation</b>

It is a function provided by the R/3 system for carrying out these control options intended to help your company to avoid critical requirement and procurement situations. This should enable you to keep production to a minimum at the same time as allowing you to react quickly to bottlenecks and changing market situations.

In the R/3 system, product allocations represent an ordered allocation of production for certain periods. Product allocations can be created according to various criteria (i.e., customer, regions).

Product allocations are created in the logistics controlling area in the planning hierarchy

<b>menu path:</b>

Logistics ---> Logist. controlling ---> Flexible planning ---> Planning create/change ---> Planning type: COMMIT for SAP standard planning type

. Product allocations are always divided right up to the lowest level in the hierarchy. The basis for the planning hierarchy is info structure "S140", which SAP issues as the standard info structure. It determines the criteria of the hierarchy.

You can define your own info structures in Customizing for LIS

Logistics General ---> Logistics Information System ---> Reporting -> Standard Analyses-> Change settings.

To carry out availability check against product allocation, certain requirements must be met:

<b>Material master</b>

In the material master, the product allocation determination procedure must be entered in the basic data screen for general data.

Statistics update

In Customizing for the Logistics Information System, statistics updating must be set for the information structure. This is required at customer, material and header level. The update group must also be maintained in Customizing for the Logistics Information System.

In Customizing for SD, the settings must be made for availability check against product allocation. You will find the necessary steps described in the Implementation Guide in section "Availability check against product allocations". This is where, the necessary Customizing activities for the statistics update are described.

The planning hierarchies for product allocations are created in logistics controlling. If the correct settings have been made in Customiuing, the system carries out an availability check against the ATP quantity in SD during order entry. If the availability check determines that the ATP quantity can fully or partially cover the order requirement, then a confirmed quantity is determined as the result of the check. The confirmed quantity is the basis for the availability check against product allocation, which is carried out along with the ATP check.

The confirmed quantity from the ATP check is checked against the relevant product allocation. This ensures that the product allocation for this period is not exceeded. Required quantities that cannot be confirmed, because the product allocation for that period is used up, are postponed until the next period.

The result of the product allocation check can change confirmed quantities that have already been determined. In this case you receive a message before branching to the availability control screen.

Unlike the ATP check, the check date for the availability check against product allocations is the planned delivery date for the customer and not the material availability date.

The actual order quantities are updated in the planning hierarchy of the LIS. Comprehensive reporting tools and an early warning system in the LIS that has to be set in Customizing monitor the status of the product allocation period and report critical situations immediately.

Product allocation uses a blocking mechanism similar to quantity block in the ATP check: The check hierarchy of the corresponding product allocation object is only blocked exclusively during the check itself. Afterwards, the same object can also be used by other processes without the current procedure having been saved. The product allocation quantity used is, however, seen in all subsequent processes (via this blocking mechanism) to prevent over-confirmation.

The system can carry out an availability check against product allocation automatically during order entry. When availability is low, you branch to the availability control screen automatically. From there, you can view the result of the product allocation.

<b>This is done as follows:</b>

In the availability control screen, branch to the display of the availability situation with regards to product allocations via Goto ---> Product allocations.

By clicking on the "product allocation" symbol, you can view the product allocation that was checked against. You can see which product allocations are available for which periods, how much the product allocation has been used up by other orders and how much product allocation remains.

<b>For example,</b>

even though the material for an order for 100 pieces may be available in full for the required date according to the ATP check, it is only partially confirmed because the product allocation for that customer only had a value of 80 pieces remaining at the time of order entry. The confirmed quantity for the required quantity and an alternative delivery date is displayed on the control screen.

regards,

Arun prasad

[Former Member]

Hi Arun,

I have typical situation in product allocation.

We have done all the configuration for product allocation and still we could not achieve the expected result.

1. When we reserve quantity to certain customers system  is not preventing other customers in confirming the stock means system is giving all the available stock.

2. The product allocation tab in the ATP view is grayed out in our example. Do you know what makes this product allocation tab  viewable?

Please help us.

Thanks

Srinivas

[former_member366475]

This message was moderated.