2018年10月17日 星期三

Availability Check 允諾量計算 ....


Availability Check
允諾量計算

Important Topics重要事項

Topics                      
Description       
Availability check
General Documentation on how ATP works 允諾交期一般文件
ATP customizing
Basic Customizing.基本客製化
Transaction CO09
How to read CO09 讀取允諾交期
Transaction CO06
Rescheduling
Accumulation
User Exits
Userexits in ATP & SD 使用者界接
Useful Notes
Useful Notes in ATP 常用摘註

 

  • No labels

6 Child Pages

General Documentation

Skip to end of metadata
Go to start of metadata

Use

During sales order processing, the availability check enables you to tell the customer if the product can be delivered on time. You can control how the availability check is carried out by setting the Availability check field in the material master. When entering a sales order, confirmation of goods for delivery to the customer at a required delivery date is only possible if the goods are available for all the necessary processing activities, which take place before delivery. Scheduling is used ,To determine the actual date.

Requirements and ATP-check in general

Requirements are generated in SD which is equivalent to a material reservation . A requirement is a set of data, that includes the information, which quantity of which material at which date is required. On the basis of that requirement the MRP-run is able to react to the situation ,if the material is not in stock ,MRP can then initiate the procurement/Production of that material. Therefore requirements are planned outward-movements of stock (issues). The requirements are also used by the availability check to ensure that already promised reservations of stock are considered to give a realistic availability calculation. 

ATP Check 

Availibility Check takes the following three logics into account :-
  • Current Stock
  • Expected Receipts
  • Expected Issues

Types of Availability check in SD

There are three types of Availability checks. You can determine In the customizing of the requirements class (OVZG),whether an availability check is to be carried out against the ATP quantity,planning or product allocation Following are the three type that you can have.
  1. Check on the basis of the ATP quantities
  2. Check against planning
  3. Check against product allocation
1. Check on the basis of the ATP quantities :
The ATP quantity (ATP = Available To Promise) is calculated from the following :  
  1. Physical stock
  2. Planned inward movements of stock (= receipts), such as production orders, purchase orders, planned orders 
  3. Planned outward movements of stock (= issues), such as sales orders, deliveries and reservations.
The types of issues and receipts that are taken into account for ATP, the ‘scope of check’ can be customized in transaction OVZ9.
2. 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 The planned independent requirements result from demand planning (PP) and are used for planning expected sales quantities independent from individual sales-orders.
3. Check against product allocation
Product allocation facilitates period-based distribution of products for certain customers (or customer groups) or regions. 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. Avoid first-come first-serve situations 

Controlling the Availability Check

Availability check can be controlled in two ways
1. General Control Features via
    • Material Master
    • Requirement Class. 
2. SD Specific Control Features
    • Checking Group 
    • Checking Rule
    • Schedule Line Category

Prerequisites for the Availability Check

An availability check can only be carried out if the following prerequisites have been fulfilled.
  • The control elements described above, must be maintained in Customizing for Sales and the relevant assignments made to the sales transactions (Sched line category, requirementent type)
  • 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

  • ATP Customising

    Skip to end of metadata
    Go to start of metadata

    Purpose

    The purpose of this page is to explain how ERP ATP check is customized.

    Overview

    Essential steps and methods for customising ERP ATP Check.

    Requirement types and requirement class determination

    The system allows the standard search strategy and two alternate search strategies. This is helpful for the customers that wish to base their requirements type/class on the sales process (triggered by the item category) rather than being limited by using only the planning characteristics of the material (= production process).

    Standard search strategy

    The system uses a series of checks to determine the requirements type. The sequence of checks are called a search strategy.
     First, the system will look for a Strategy Group. This is maintained in the material master (MRP view). The requirements type is defaulted from the strategy group in OPPT. The details of the strategy group can be viewed within transaction OPPS.
     If there is no strategy group maintained, then the system looks at the MRP group, from the material master. The plant and the MRP group are used to determine the strategy group, which will determine the requirement type (using the method described above).  This configuration is found within transaction OPPU.
     If there is no strategy group and  no MRP group exists in the material master,  the system will then look at the material type as maintained within transaction OPPR. MRP group = Material type.  The system will use the MRP group information to derive the strategy group, etc, as described above.
     If there is no strategy group and no MRP group in the material master, and no MRP group equals the material type, then the system will look at the Item Category and MRP Type to find the Requirement Type. This is configured within transaction OVZI. It is also possible to have configuration with the Item category + BLANK = requirements type within the table.
     Finally, if the system has been unable to determine a requirements type by using the steps above, the system will leave the field blank in the sales document.

    Alternate search strategies


    Item category and MRP type (1)
     The standard search is performed and the entry from OVZI (Item category + MRP type) is used as the Requirements type even if this is not a valid requirements type from the standard search. It is still possible to enter different requirement types manually, since more than one valid requirement type is possible because there can be several Strategies within a Strategy Group.
    Item Category and MRP Type with validity check (2)
    The standard search is performed and then the Requirements Type from OVZI (Item Category + MRP type) is used ONLY if it is valid from the standard search method. If the entry from OVZI is not valid then the requirements type derived from the standard search method is used.
    If the Item Category + MRP type combination cannot be found on transaction OVZI, you can add a new entry on the customizing transaction VOV5. 
    Note: If you want to find the requirements class without checking the configuration, go to the schedule line screen and hit ‘/H’ and check contents of XVBEP. The fields are BDART and PLART. The fields must be combined to get the actual requirement class.
     Example
    BDART = 04
    PLART = 1
    Requirement class = 041

    Illustration of ERP ATP Customizing.

    1.Material Master: relevant fields: 
    • MRP1 View:  MRP type, MRP group.
    • MRP3 View :   Strategy Group.
    • Sales org. 2:  Item Category Group
    2.DEBUGGING: relevant fields:
    • xvbap-pstyv = Item Category
    • xvbap-bedae = Requirements Type
    • xvbep-bdart + xvbep-plart = together in this order show Requirements Class

    Detailed Customising for Required for Sales order

張貼者： 於

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)