Skip to Content
avatar image
Former Member

Availability and TOR

Hi all,

Please Provide your views on my doubt.

Which one is first happen? TOR or Availabilty check at sales order level and at delivery level.

Muthupandiyan

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

7 Answers

  • Best Answer
    avatar image
    Former Member
    Oct 15, 2007 at 05:25 AM

    Hi Muthupandiyan

    Availability happens first. Then only TOR happends. Once u save ur order.

    Then in go and check in Stock Requirements List MD04. Requriment

    transfers only after saving ur sales order. So only Availability happends first.

    Then TOR happends

    Reward if useful to u

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hi all,

      Thanks for response. I know How to configure the TOR and Availabilty check.

      Still my doubt is not clear

      The first pre req for availability check is activation of TOR at req class level. With out this we cant able to activate availabilty check at all. so this seems no availabilty check with out TOR. Then how will we decide that Availabilty check is happening first.

      Muthupandiyan

  • avatar image
    Former Member
    Oct 14, 2007 at 05:18 PM

    hi

    Availablity check will happen first in the sales order giving the date and then the requirements are passed through TOR any way both are interlinked and twined together.

    regards

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Oct 15, 2007 at 05:19 AM

    Hi Muthupandiyan,

    <u><b>TOR</b></u>Performing transfer of requirements is dependent on a number of factors. They determine whether and how requirements should be transferred and if they should be checked against planned requirements. The transfer of requirements in sales can be switched on or off by transaction as required. For example, you can switch off the transfer of requirements for inquiries and quotations, whereas you can switch it on for sales orders and deliveries.

    <u><b>Availability check</b></u> 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.

    Regards

    Srikanth.A

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Oct 15, 2007 at 05:27 AM

    Hello Muthu,

    <b>Availability check is considered as a Pre-Sale acitivity and TOR is a Post sale activity.</b>

    Availability check can be carried out even at the quotation level as per the business requirement to understand if the required delivery date can be met or not.

    On the other hand, TOR happens only after a sales order is saved. Requirements are transferred to the material planning department to produce/procure the required goods and deliver the same on the relevant delivery date.

    The same principle applies at the delivery level also.

    <b>Reward points if helpful</b>

    Regards

    Sai

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Hi Sai,

      I mean there is a chance to do a availabilty and TOR at quotation level. From This TOR we can able to control the percentage of the qty to transferred to the MRP. its all based on the Expected order value.

      Muthu

  • avatar image
    Former Member
    Oct 15, 2007 at 05:44 AM

    Hi Muthu,

    As per my knowledge, First TOR happens then Availability check.

    When we create sales order, each line item is created as a schedule line.

    The Schedule line represents the customer intended delivery date and quantity to be delivered.

    This information is transferred as TOR to Material Requirements Planning(MRP).

    MRP then checks if the enough stock is available for the required date.

    Then based on the check forward scheduling, backward scheduling takes place.

    Award points if it adds information.

    Thanks

    Mohan

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Oct 15, 2007 at 06:07 AM

    dear muthupandiyan

    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 &#61664; S&D &#61664; Basic functions &#61664; Availability Check & Transfer of requirements &#61664; Transfer of requirements &#61664; 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).

    rewards if it helps

    siva

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Oct 15, 2007 at 07:04 AM

    Hi Pandiyan

    check out this link it may add up to u r knowledge

    hi

    Add comment
    10|10000 characters needed characters exceeded