Purpose
The purpose of this page is to explain the customizing and important settings of the availability check.
Overview
- General settings
- Checking group - transaction OVZ2
- Material Master - transaction MM02
- Scope of check - transaction OVZ9
Customizing of the Availability Check in ERP
The first prerequisite in order to be able to carry out an ATP check is to set up a checking group and to assign it to your material in the material master.
The checking group you can create in transaction OVZ2:
Let us have a closer look at the different settings of the checking group:
Fields ’TotalsSales’ and ’TotDLvReqs’ is a setting that determines where and how requirements of sales and shipping documents are stored. ’TotalsSales’ is for sales documents and’TotDLvReqs’ is for deliveries. You have to decide whether you would like to store single or summarized requirements. SAP recommends to use single requirements. Single requirements are stored in table VBBE. Single requirements means that for every single schedule line a record will be created in table VBBE. If you are using summarized requirements then they are stored in table VBBS. Here you will get one record for several sales order items that lie e.g. on the same date. Table VBBS has no information about the document number and this table is used in transaction MD04 and Co09 to display the requirements of sales and shipping documents. VBBS has been introduced when memory was limited and expensive. Nowadays there is not much reason to use summarized records. If you do not maintain these settings then no requirements will be created as the system does not know where to store the requirements. So in order to have a transfer of requirements you have to fill in these fields.
There are some cases when the requirements are written into VBBE even if according to this customizing you suppose to find them in VBBS. These are the cases when necessary information would be lost if they were written in VBBS. In case of dynamic assembly process but also other scenarios with special stock (SOBKZ), APO-checked materials, ICON check and MRP areas only individual requirements can be written.
The next setting ’Block QtRq’ is one of the blocking concept that is available in the ERP system. SAP recommends to set this setting here in transaction OVZ2. During the ATP check blocking ensures that the same available quantity cannot be allocated several times when doing the ATP in parallel sessions. There are 2 blocking concepts for availability check: 1. Hard block: in transaction OVZ1 set the indicator ’Block’ (TMVFP-VFPSP). In transaction OVZ2 the indicator ’Block’ (TMVF-ACENQ) is not set. During the availability check, the material is blocked for other users. The block remains until the transaction has been saved. If you have performed an ATP check in one session but you haven't saved the order yet then in parallel sessions it is not possible to perform an ATP check. I.e. parallel processing of the same material is in general not possible. A parallel ATP check will give the result: ’No availability check can be carried out for material Message no. V1082’ 2. Soft block: in transaction OVZ2 the indicator ’Block’ (TMVF-ACENQ) is set. In this case the hard block in transaction OVZ1 TMVFP-VFPSP is not relevant whether it is set or not.) Set this block if you want several users to be able to process the material simultaneously in different transactions without blocking each other. If you have performed an ATP check in one session but you haven't saved the order yet then the ATP data are written in an enqueue record into the enqueue table (table ATPENQ) on the enqueue server. In parallel sessions an ATP check reads these records and take them into account. The lock entries should be deleted when you are leaving the transaction. Thus, parallel processing of the same material is possible and the ATP-check gives meaningful results. SAP recommends to use the soft block.
When setting the flag for ’No check’ then the ATP check is not carried out.
The setting for 'Accumulation' is a very important setting. It can avoid over confirmation situations. SAP recommends to use accumulation ’3’. The accumulation is important for two different things. The first is that dependent on this setting the system can behave differently when creating or changing the document. When setting accumulation to the recommended value ’3’ then the system will take into account required quantities when creating the document. What does this mean exactly? The system checks whether the required quantities of the documents can be covered by the stock and receipt elements. If not then you will not be able to confirm a new sales order when creating. When you change the document then the system checks whether the confirmed quantities can be covered by the stock and receipt elements. If yes and further available quantity remains then you will be able to confirm a further requirement. To make it more clear please check the following example.
Stock 100 required quantity confirmed date
Sales order 1 100 0
When accumulation is set to ’3’ then you will not be able to confirm a further requirement because the system checks with required quantities. Sales order 1 has a requirement of 100 and is so blocking the 100 on stock. There is no further available quantity for a further requirement during creation. When you create a further sales order e.g. sales order 2 with quantity 60 nothing will be confirmed. When you save the sales order and you reenter it and you carry out a new ATP check then you will receive a confirmation. While changing the ATP check is carried out with confirmed quantities. Sales order 1 has no confirmed quantity so 100 are available when you change sales order2 and you carry out a new ATP check.
If accumulation is set to ’1’ then system checks with confirmed quantities during creation and changing. Please check the F4 help in the ERP system for the field accumulation.
The second thing for which accumulation is important is to avoid over confirmation. Please check the F1 help in the ERP system. It provides you an example that highlights what can be happen when you do not use accumulation.
Please also have a look at the example below which provides you a graphical description how an over confirmation can happen when moving receipt elements on the time axis.
The next setting
‘Response’ controls whether you receive an information message when carrying out the ATP check that you have a shortfall. The message that is raised is: The sum of the requested quantity exceeds the sum of stock items (Message no. VV041)
The last setting ’RelChkPlan’ controls whether for a component the check against planning should be carried out.
The checking group has to be assigned in the mateial master. You have two options to maintain this int he material master. On the view ’Sales: General/Plant’ and the ’MRP 3’ view.
The second prerequisit for the ATP check is the checking rule. The checking group together with the checking rule establish the scope of check which can be maintained in transaction OVZ9. Further information regarding the checking rules you will find on the pages with the application specific settings like e.g. SD/LE specific settings. Now we will have a closer look to the scope of check.
In the scope of check you can control which stocks, receipts and issues should be considered during the ATP check. Please check the F1-help of the different fields. In this documentation only some of the settings will be explained that sometimes are misunderstood. ‘StockIn Transfer’ is often mixed up with the stock in transit. The stock in transit cannot be considered in the ATP check. When doing a two step (goods issue and goods receipt in two different steps) transfer posting via e.g. transaction MIGO then we are talking about stock in transfer. So in this case you post the goods issue into the stock in transfer and later on you post the goods receipt out of the stock in transfer. When you work with stock transport orders then you can create a delivery for the stock transport order. When you post goods issue for the delivery then depending on the movement type you can post it into the stock in transit. Later on when you post the goods receipt for the stock transport order you can post it out of the stock in transit into your stock. So in case of stock in transfer you only do a transfer posting. In case of stock in transit you have MM and LE documents for which you post goods issue and goods receipt.
‘W/o subcontracting’ controls not only the subcontracting stock but also the subcontracting requirements. There is no possibility to separate this. When you include the subcontracting stock then automatically the subcontracting requirements are included.
Regarding
‘Check without RLT’ there is Knowledge Base Article
2135782 - Calculation of the Replenishment Lead Time which explains exactly how the calculation happens. When you are checking ATP with RLT then everything that lies after the replenishment lead time will get a confirmation independent of whether you have available stock or not.
‘No stor.loc.inspectn’ deactivates ATP check on storage location level. If batches are involved then also the batch/storage location level will not be checked. The ATP check is carried out only on plant level and in case of batches also on batch level.
In the material master you can set whether a storage location should be planned separately.
If you plan a storage location separately then the setting ‘No stor.loc.inspectn’ has no effect. In this case the ATP check is only carried out on storage location level and in case of batches also on batch/storage location level. The setting in the material master overrules the setting in the scope of check.
‘Incl.Purchase Orders’ controls whether you would like to include purchase orders. It also controls the stock transport order on the receiving side. When you maintain value ‘X’ then purchase orders are considered and stock transport orders are considered with the whole requested quantity. This means e.g. you have a stock transport order with a requested quantity of 100 and a confirmation of 60 then on the receiving side 100 will be considered as receipt. Setting the value to ‘A’ the system will consider only the confirmed quantity on the receiving side. Considering our example the system will consider 60 as receipt. This setting has no effect on transaction MD04. In MD04 you will see the whole requested quantity on the receiving side. In the MM customizing you have a setting that controls also transaction MD04 in this regard. Further information you will find in Knowledge Base Article
2195518 - Everything about stock transport orders and the ATP check
‘Incl. dependent reqs’ controls whether you want to include the requirements of the planned order components. In planned orders there is no automatic ATP check. You have to trigger the ATP check manually by pressing the availability check button.
‘Include Reservation’ includes the material reservation that can be created via transaction MB21. This setting is not relevant for reservations for components of a production order. Also in material reservations you can carry out an ATP check.
‘Incl.ship.notificat.’ controls whether you would like to consider shipping notifications. Please consider that shipping notifications are automatically considered when you include purchase orders ‘Incl.Purchase Orders’. So this setting is only relevant when you do not want to consider purchase orders but you want to consider shipping notifications. Please consider Knowledge Base Article
1890026 - Shipping notification in the availability check
‘Incl.depen.reservat.’ controls the requirements for components of production orders. If you want to consider them then you have the option whether you would like to consider all reservation or only reservations that come from already released production orders. The last one is controlled by the value ‘A’ -Only include withdrawable reservations.
‘Incl.rel.order reqs’ controls the requirements of stock transport purchase requisitions and orders (supplying side)
Related Content
Fonte: https://wiki.scn.sap.com/wiki/display/SD/General+Customizing+Settings+of+the+Availability+Check
