Available-to-Promise (ATP)

The main target of the demand fulfillment process is to generate fast and reliable order promises to the customer and shield production and purchasing against infeasibility. The quality of the order promises is measured by the on-time delivery. For that, the business function (Available to Promise (ATP)) is responsible to provide the customers and internal departments with the available quantities of the requested product and the corresponding due dates for them to expect delivery.

Section 1 Basic concepts

Available-to-promise: processes
advanced ATP
Configuration
Accumulation
Including Replenishment Lead Time
Customizing/Master data parameters with the influence on ATP
Allocating and Reducing Independent Requirements in SD
Material Block For Other Users
Scope of the check
Requested DD on a non-working day

Section 2 Operation level

Availability Check in Shipping
Blocking Confirmation
Fixing Quantities and Dates in Sales Documents
Delivery Agreements in the Customer Master Record
Reactions to the Availability Check in Sales Documents
Everything about transaction Co09

Section 3 Some words about processes

Availability Across Plants
Product allocation
Available-to-Promise on the Internet
Timing of the Availability Check (SD)
Rescheduling
Backorder processing
Alternative-based-confirmation (ABC)
ATP in Production ( update: 06.11.2020 )
ATP in Inventory Management and Physical Inventory ( update: 07.09.2021 )

Section 4 Additional information

FAQ/SAP notes and additional references

How to fix inconsistencies?
3004240 - Availability check despite enabled delivery date and quantity fixed indicator
2769819 - BAPI MATERIAL AVAILABILITY Lead Time based on Planned Delivery Time
2799290 - Stock can be issued out although it is reserved
2920200 - Why availability check is not working as expected in Inventory Management (MM-IM)?
2786800 - Wrong requirements date when scheduling via planned delivery time in a stock transfer scenario
154682 - Availability check doesn't take batch into account
547118 FAQ: Result of ATP calculation
547512 FAQ: Customizing the ATP in R/3
607036 FAQ: Product allocation in R/3
548779 FAQ: Delivery units during the availability check
766475 FAQ: ATP check and confirmed quantities of stock transport orders
547277 FAQ: Requirements in SD and in the delivery
606282 FAQ: Returns processing, requirements and ATP
547508 FAQ: Schedule line overview and ATP
549064 FAQ: Rescheduling/backorder updating in R/3
546965 FAQ: Correlation and delivery groups in SD
547961 FAQ: Shipment and transport scheduling in R/3
146829 Process flow of route schedule
99999 ATP server: Installation and sizing
25444 SDRQCR21: Recovery of sales and delivery requirements
FAQ notes for related subject areas:
799948 FAQ: Dynamic assembly
764611 FAQ: Static assembly
321803 Explanatory notes on ATP Customizing (for production orders)
622299 Consulting: Availability check against planning
498149 FAQ: Availability check in purchasing
548510 FAQ: Confirmation function in R/3, confirmation schedule lines
619911 FAQ: Batch determination
842829 Replenishment dely from stock trans order: Special features
Notes on further ATP relevant topics with consulting content:
873606 Rounding problem results in different confirmations
2195518 - Everything about stock transport orders and ATP

Section 5: Enhancements

BADI
Engine

Section #1 Configuration and the basics

Master data

Customer and Customer-material records contain default parameters for complete/partial deliveries.

It can be changed manually at the header, item levels in SD document.
Use cases: The customer wants complete delivery of all items by the requested delivery date or at a later date, the customer only allows a certain number of partial deliveries for each item.

The material master contains the Checking group and...

In the material master record, we specify on the Sales/Plant Data screen in the Availability check field whether each requirement is forwarded individually or combined.
- Individual requirements have the advantage that the initiating document can be identified.
- Collective requirements (criteria: Plant/Batch/Storage location/Date/Transaction/Requirements Class) can either be created daily or weekly. This is useful for dealing with a large volume of sales orders.
MRP1 View: MRP type, MRP group.
MRP2 View: planned delivery time, in-house production time.
MRP3 View: Strategy Group, total replenishment lead time.
MRP4 View: The storage location 'Sloc MRP indicator' is set to '1' or '2' .

In this case, the storage location quantity is not added to plant stock.

Sales org. 2: Item Category Group.

Available-to-promise: Processes

The type is defined at the requirement class type level.

Check on the basis of the ATP quantities

The ATP quantity (ATP = Available To Promise) is calculated from the following :

Physical stock
Planned inward movements of stock (= receipts), such as production orders, purchase orders, planned orders
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.

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.

Check against product allocation

Product allocation facilitates the period-based distribution of products for certain customers (or customer groups) or regions.

Rule-based ATP
advanced ATP (S4/)

Available-to-Promise on the Internet

Using transaction SU05, we can create, change and delete passwords for Internet users. Activities involved in including the own product catalog

Create a product catalog in the SAP System’s product catalog maintenance screen.
Use the report PCATALOG to create the input files for the Java applet.
Place the input files for the Java applet on the Web server.
Adjust the applet parameters on the HTML page to the new files.
Based on FM BAPI_MATERIAL_AVAILABILITY.

The batch status determines whether a batch is available or not: a batch is available as soon as it enters a stock type that is included in the availability check.

Advanced ATP

It is optimized for large orders and for mass processing. It is activated separately and the license is required.

We cannot combine aPAC and against planning.
It does not work with Active ingredient management
The application log for aATP can be activated !

Fiori apps

Monitor material coverage app
Monitor Coverage Net and individual segments

Components

Product availability check
Backorder processing: to check material avail. when the demand/supply has changed and we want to check if previously calc. confirmations are realistic.

Within backorder processing the system selects items in SD and stock transfer documents. Then ATP check is carried out for the items.
aATP must not be activated.

Product allocation , apps

Product allocation object
Manage product allocation planning
Manage product allocation sequence
Assign product to product allocation

Alternative based confirmation
Release for delivery: to prioritize documents with limited material availability

Display sales orders containing this material
Display potential financial impact
Manually redistribute quantities between sales orders
Apply confirmation strategies
Release materials for delivery

Timing of the Availability Check (SD)

The ATP check in SAP ECC is accurate to the day. The day begins at 00:00 in the time zone of the plant (local time) in which ATP takes place.

Technically all receipts are available at the beginning of the day, even it is not true.

The system determines the required material availability date on the basis of the customer’s requested delivery date based on the following objects:
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

Transportation and Delivery Scheduling

Please, see: Transportation and Delivery Scheduling

Configuration

Strategy group
Main strategy and further possible strategies. The planning strategy specifies the requirements type for planning and customer requirements
MRP group: the strategy group, consumption mode, and planning period
MRP type and item category
Requirements Class (... relevance for planning, requirements planning strategy, and requirements consumption strategy )
Requirements type
Checking group ( whether the system is to create individual or collective requirements in sales and shipping processing )
A material block for the availability check with the transfer of requirements can be set here
The checking group specifies in combination with the checking rule the scope of the availability check.
Checking rule to control the scope of the availability check for each transaction in sales and distribution.
Schedule line category
At the schedule line level when the availability check is switched on, the transfer of requirements can be switched off
Delivery item category

Including Replenishment Lead Time

Replenishment lead time is the time that is needed to order or produce the requested material. Depending on the material type, replenishment lead time can be calculated according to various time periods.

If the material availability date is calculated on the basis of the current date to lie after the replenishment lead time for the item, the item itself can be confirmed despite the insufficient stock being available. In this case, the system assumes that any quantity requested by the customer can be procured by the material availability date and considers the goods to be available.

Procured in House:
-> Total RLT
-> Production time + GR time
Externally procured:
-> Purhcase processing time + planned delivery time + GR time

Availability Check Including Replenishment Time

The calculation of the RLT is dependent on the procurement type of the material (MRP2).
If procurement type = F, planned delivery time is taken (MRP2)
Else (type E or X) the total replenishment lead time (MRP3) is taken if > 0
If Total RLT = 0,
inhouse production time (MRP2) is taken if > 0
If inhouse production time = 0, the sum of setup time and interoperation time is taken (work scheduling from view).

Availability is only checked up to the end of replenishment lead time.
for in-house produced goods, the overall replenishment lead time is required,
for externally procured materials, the planned delivery time, the processing time for goods receipt, or the processing time for purchasing is required.
Performing the availability check including replenishment lead time only makes sense if materials planning is carried out at regular intervals (best of all, daily for individual and daily requirements and weekly for weekly requirements).

Availability Check Excluding Replenishment Lead Time

The quantity can only be confirmed on the date on which availability can be guaranteed again as a result of planned inward movements of stock.
Note: Field 'check without RLT' Indicates whether the system checks the replenishment lead time or not. Please review the SAP Note 1604270 for more details.

Accumulation

Carried out without the cumulative quantities being taken into account, this can lead to more being confirmed than is available. The system checks whether ATP quantities arise in the period before the delivery date. If so, the new sales order reduces the ATP quantities, if the ATP dates come before the delivery date.
If a planned inward movement of goods is delayed to the desired date after the confirmed date, then the confirmation of the sales order remains in place without a stock coverage being given.
A newly created order could be confirmed because of the delayed inward movement of goods and lead to more being confirmed than is available.
To avoid this situation we recommend using accumulation rule 3 in transaction OVZ2.

Product allocation

What to check (configuration)?

Check the essential basic settings for product allocation
Product allocation must be switched on in the requirement class (transaction OVZG) and in the schedule line (transaction VOV6).
The transfer of requirements must be switched on in the required class and in the schedule line.
The availability check must be switched on in the required class and in the schedule line.
The product allocation determination procedure has been maintained in the Basic data 1 tab in Material Master.
Check the update settings
Check the updated setting of the info structure in the transaction MC25.
If we use your self-defined info structure, we can use formulas 141 - 144 as a copy reference and we must adjust them to the info structure.
The key figure incoming orders quantity (AEMENGE) must be updated. The update must occur on schedule line level (quantity and date are transferred from schedule line, MCVBEP). The formulas of the characteristics are processed on the schedule line level. The update date is the delivery date (EDATU).
Check the validity of the product allocation object and the factory calendar
Check the validity of the relevant product allocation object in transaction OV4Z (V_T190-KTGBI). Make sure that the data maintained here is inside the validity of a factory calendar.
Check the validity of the factory calendar of the shipping point and the factory calendar of the route. Make sure that the validity of both calendars is maintained at least 2-3 years into the future.

Item rejected

(!) In product allocation, if we reject a sales order item (by setting the reason for rejection) the key figures for incoming orders are not reduced in the information structures. While deleted sales order items still reduce the key figures for incoming orders.

Something more about rejected items:
In the standard system, the Sales Information System does not take field MCVBAP-ABGRU into account, that is, all key figures are updated. The open items and values, however, are excluded from this since these are not calculated for completed items (overall delivery status MCVBUP-LFGSA = "C") and rejected items have the status "C".
In Customizing of the reason for rejection (Transaction OVAG), we can control whether the values of the rejected items are cumulated on the header level.
If this is deactivated, during the update of, for example, the net value (NETWR) from the item level, the reason for rejection is not taken into account.
However, it is taken into account during the update of the net value from the header level since VBAK-NETWR only results from the total of the items which are not rejected.
If we set a reason for rejection for a partially delivered item, in general, incorrect figures occur in the statistics. The reason for rejection does NOT refer to the remaining quantity but to the entire item! Consequently, it also does not make sense to set a reason for rejection for partially delivered items if only the remaining quantity should be rejected. Instead of setting a reason for rejection, then the quantity itself should be reduced.

Collective product allocation

Requirements for collective product allocations:
In the planning hierarchy of the info structure, we only create fully specified characteristics combinations
In Customizing for the product allocation we create a characteristic indicator for collective product allocations
In Customizing for the product allocation we automatically generate all possible collective product allocations (Report RMQUOT01)
If specific collective product allocations are not required, delete these entries again in the planning hierarchy
We can also create collective product allocations via report RMCP3INS

Unit conversion

The unit of measure of the planning parameter of the information structure (Transaction MC7F) is the base unit of measure.
So that the planning can occur in any unit of measure, an additional key figure is required for which the amounts are converted into the product allocation quantity via a macro.
However, wewant to plan the product allocation quantity (KCQTY) in any unit of measure and also display the result of the quantity of the incoming order (AEMENGE) in any unit of measure. We can achieve this by creating two new key figures, for example, KCQTY_NEW and AEMENGE_NEW, and by creating a macro for each key figure. The macro for KCQTY_NEW converts the quantity to the base unit of measure and stores it in key figure KCQTY. The macro for AEMENGE_NEW reads the quantity of the AEMENGE and converts it to any unit of measure and stores it in field AEMENGE_NEW
For the implementation of the macro, refer to the Remote Consulting of the LIS.
The unit of measure of the planning parameter of the information structure (Transaction MC7F) is any unit of measure.
In this case, a quantity conversion can only be implemented in the update if we can make sure that only the incoming orders quantity is updated and that the account assignment schema has only one step (only one product allocation group is updated).
It does not work with:
third-party order processing or individual purchase order processing
static or dynamic assembly processing
Scheduling agreements with JIT delivery schedules or forecast delivery schedules
The product allocation determination procedure is entered in the basic data for the material master and is valid for all plants for the material. In the APO System, the plant-specific use of product allocation is a standard function; in the R/3 System, it is not. Nevertheless, this function can also be set up in the R/3 System by maintaining the plant as a characteristic. However, if there are plants for which no products are to be allocated, we must group them together in a collective product allocation. We should always plan this collective product allocation with a sufficiently large quantity.

We can group together only materials that have the same base unit of measure in an information structure.

The combination of returns with product allocation is not recommended in the standard SAP system, since it can result in inconsistencies (negative receipt quantities).

Customizing/Master data parameters with the influence on ATP

Customizing

The control elements described above must be maintained in Customizing for Sales and the relevant assignments made to the sales transactions (Sched line category, requirement type)
The availability check must be switched on at the requirements class level and - for the availability check in the sales documents - at the 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
We use a combination of availability check group (CH) and checking rules to control whether or not restricted batches are to be considered during the availability check.

Please, see the references for more details.

Allocating and Reducing Independent Requirements in SD

Independent requirements from planning are reduced by the goods issue posting in the delivery. The quantity decrease is determined from the consumption quantity which is transferred for the relevant item in the underlying order, as well as from the appropriate consumption period and mode.

We enter the consumption mode and the consumption period in the MRP 3 screen in the material master record.

Prerequisites:
Using a planning strategy that includes the consumption of customer requirements and planned independent requirements
In the planning strategy (transaction OPPS), we have maintained requirement types for the planning and the sales order.
The consumption indicator of the requirements class of planning is identical to the allocation indicator of the requirements class of the customer requirements.
the indicator for the availability check against ATP is not set in the requirements class of the customer requirements.

Maintenance of consumption mode and consumption periods in the material master or the MRP group of the material

The general process of the availability check against planning

The system selects all planned independent requirements of the material that can be consumed with the requirements type of the sales order.
The system reads all other consumption elements from the database that are consumed against the corresponding planned independent requirements (customer requirements, manual and dependent reservations, dependent requirements, and so on ).
The selected consumption elements are consumed against the planned independent requirements.
From the requested date of the customer requirements to be checked onwards, the system searches the corresponding consumption periods for free planning quantities that are not already consumed.
Quantities that can be assigned to free planning quantities before the requested date via backward consumption are confirmed for the requested date of the customer requirements.
Quantities that can be assigned to free planning quantities after the requested date via forwarding consumption correspondingly receive later confirmation dates.

Availability check against planning with assembly

Consumption/allocation indicator = 1
PIR-s with consumption indicator '1' are relevant for production; the planned material is manufactured on the basis of the planning and corresponding stock levels are set up. It is assumed that the dates of the planned independent requirements are known in advance so that the procurement can or could always be performed for the planning date.

This means that a customer requirement with a requested date of today can also be confirmed today if there are enough free planning quantities in the backward consumption interval in the past. It is assumed that these planning quantities were produced in the past and exist as free warehouse stock at the time of the availability check.

Availability check against planning without assembly

Consumption/allocation indicator = 2

Not relevant for production. Planned independent requirements of this type are generally used in make-to-order scenarios, and are used for procurement and storage at lower-level non-variable part levels. However, the planned material is not manufactured on the basis of the planning.

An availability check against the corresponding PIR must also take into account the replenishment lead time (in-house production time, lead time) of the planned material. In this case it is assumed that, parts were procured on time. Only the assembly of the finished product must be carried out to fulfill the customer requirements.

All checks for customer requirements that are within the replenishment lead time of the planned material are critical. Even if the assembly is started immediately, the earliest time that the corresponding requirements can be covered/confirmed is at the end of the replenishment lead time.

When calculating the end of the replenishment lead time, both the lot size dependent and the lot size independent in-house production time of the material are taken into account. This means that the confirmation dates may differ when planning is sufficient because there are different requirement quantities in the sales order.

Availability check against planning with planning material

Consumption/allocation indicator = 3

Not relevant for production. ThesePIR-s are used only for procurement and storage at lower-level non-variable part levels in make-to-order scenarios.

The most important thing about these planned independent requirements is that when we use the corresponding planning strategies, we can procure the components for different make-to-order materials centrally via the planning of a shared planning material.

Planning material

We can create a common planning material and assign similar materials to it. Independent requirements are created for the planning material to cover the requirements which are expected for the materials assigned to the planning material. Thus, customer requirements for these materials are consumed by the independent requirements of the planning material.

We assign the planning material to the materials on the MRP 3 screen and must also enter the appropriate strategy group for planning with planning materials on the MRP 1 screen.

Material Block For Other Users

Define for each checking group and initiator whether the material master record should be blocked for other orders during the availability check. If it is blocked, we cannot create two orders for the same material at the same time.

Checking Rule For Updating Backorders

The checking rule entered here is used in production planning. During backorder processing (CO06) and the availability overview (CO09), we should make sure that we are not using any checking rules that deviate from the SD configurations (checking rule A for orders and checking rule B for deliveries). It is set at the plant level.

Rescheduling

When rescheduling is performed, the open sales document items in the item index for the material are processed. The items found by this process are sorted according to the criteria delivery priority, date, document number, and item number and forwarded to the availability check. The results are then saved.

Rescheduling in SD

Rescheduling allows the redistribution of already confirmed quantities to other documents.

The program SDV03V02 takes the selected documents and unconfirmed them all.

Then they are rechecked, one after the other, based on the customizing customer has set priorities of sorting can be customized to a much finer level.

Delivery priority
The date the document was created
Number of the sales document
Alternatively, the flag in V_V2 can be set to consider the delivery date instead of the creation date.

Data processing:

Main module: XTAB_CHECK_AND_SAVE.
Records of the internal table are read one by one, checked against ATP, and saved with new results.
Correction records’ are created to track and memorize the results of the availability check.
An error during the process will leave the ATP-situation unchanged.

Rescheduling Transaction (V_V2) in Purchasing

It is not possible to transfer the result of the availability check for Purchasing documents into new schedule lines like in SD documents.

As an alternative, we can 're-distribute' purchasing documents if the availability situation changes by running transaction V_V2 for:

Stock Transport Orders
Stock Transport Requisitions
Stock Transport Scheduling Agreement
Sales Orders

Set the 'Fixed date and qty' indicator for the item in the stock transport order. to exclude it from rescheduling.

Note: batches are not taken into account.

Scope of the check

Include safety stock

This option prevents the subtraction of safety stock from available inventory. In the example above Safety Stock would be checked. With this option checked the Stock Line in CO09 should match the Stock Line in MD04. With it un-checked the Stock Line in CO09 should be the result of subtracting Safety Stock from current stock.

MRP Elements Impacted: None

StockIn Transfer

Stock in transfer should not be confused with stock in transit, that is used in the two step Stock Transfer Order process involving a Stock Transfer PO, Outbound Delivery, and subsequent goods receipt.

StockIn Transfer only applies to stock put into an in transit status, such as with a manual 313 goods movement to place stock in transit between two storage locations or a 303 to place stock in transit between two plants. With this box checked the quantity in transit is added to the stock line of the destination plant or storage location. Without this checked the stock in transit is completely unavailable and ignored, both at the sending and receiving locations.

MRP Elements Impacted: None

Incl.quality insp. Stock

For QM managed materials this will include Quality Inspection lots, maintained through transaction QA02, and will show the lot as available inventory on the Inspection End Date for the lot. Each lot is separately listed with its MRP Element.

For materials that are not QM managed this will include stock that is posted into Quality Inspection Stock. Quality inspection stock can be posted to manually through transaction like MB1C using standard movement types 503, 523, or 563. Quality inspection stock is included as part of the total stock line that is available.

MRP Elements Impacted: QM-Lot

Include restricted Use Stock

Applies to batch inventory when batch status management is active. When this flag is checked then batches that have a restricted status are included along with the unrestricted.

Include blocked stock

Includes stock that is in a block status, such as stock that is posted into Blocked Stock using movement type 505. This inventory is represented as part of the total stock. This does not impact material that is received into Goods Receipt Blocked Stock, such as material received with movement type 103. Material Received into Goods Receipt Blocked Stock will continue to display as a POItem.

MRP Elements impacted: None

Incl.ship.notificat.

This option is only relevant if the Incl.purchase orders option is blank. This option will only include Purchase Orders that have a shipping confirmation. If the Incl.purchase orders option is set to either A or X then Shipment Notifications are always taken into consideration, regardless of this setting.

MRP Elements: ShpgNt

Incl.depen.reservat.

This option will include component requirements for Production Orders. There are notes from SAP regarding this option and its applicability to purchase orders. I have only used this option to manage reservations related to Production Order components.

MRP Elements: OrdRes / Related Transactions: CO01, CO02

A – Only include withdrawable reservations. This option will only include requirements related to release Production Orders. Order Reservations for production orders that are not yet released will not be considered.
X – Include all reservations. This option will include all production order reservations.

W/o subcontracting

With this flag checked stock provided to vendor is removed from the availability check. This also removes and requirements that the subcontracting process may place on component plant inventory, meaning that SubReq MRP Elements will not be reflected in Demand, this would have the greatest impact on a material that was both a subcontracting component for one process and itself a subcontracted material.

This will not impact the inclusion of the POitem or PurRqs elements related to a subcontracting PO being placed with a vendor.

MRP Elements impacted: SubReq

Incl. dependent reqs

Includes the dependent requirements generated by the component demand of planned orders. These requirements are included for all planned orders, regardless of being MRP generated, Component Checked, or Capacity Scheduled.

Requirement Date: Start Date of the planned order

MRP Elements: DepReq

Incl.purchase orders

There are three options when including purchase orders, which include all forms of purchase orders, such as purchases from vendors, stock transfer orders, and inter-company stock transfers, and returns to vendor. These options only apply to the receiving quantities for purchase orders. The outbound requirements for stock transfers are controlled through the Incl.rel.order reqs option.

Incl. purch.requistions

Include Purchase Requisitions in availability check.

Availability Date: Delivery Date from PO Line Item + GR Processing Time.

MRP Elements: PurRqs

Include reservations

This is not to be confused with Production Order Component reservations, which controlled by the Incl.depen.reservat. option.

This option will include demand from reservations made through transaction MB21.

Availability Date: Base date of the reservation.

MRP Element: MtlRes

Include Sales Reqmnts

Includes demand generated from Sales Orders, Scheduling Agreements and other types of SD documents that are configured for requirements, depending on configuration this could include Inquiries and Quotes.

MRP Elements: CusOrd, SchAgr

Include Deliveries

This option is specific to SD deliveries and does not impact outbound STO deliveries or inbound purchasing related deliveries. This option will place a requirement on the material availability date of the delivery line.

MRP Elements: Delvry

Incl.rel.order reqs

This option is to include the demand for the supplying plant of stock transfers, either related to purchase reqs or purchase orders.

Incl. planned orders

This option includes the receipts from Planned Orders. This option should be carefully considered as planned orders are often created automatically by the MRP process.

MRP Elements: PldOrd

Transactions: MD11, MD12, MD01

Incl. production orders

This option includes planned receipts from production orders.

MRP Elements: PrdOrd

Include receipts from past and future

This option takes into account all planned receipts, based on the other options that are chosen, regardless of the date of the planned receipt.

Delivery Date on a non-working day

On Sales Orders, it is possible to have delivery dates being calculated at non-working days, like weekends or holidays. This is possible when the user enters a Requested Delivery Date (or a Delivery Date on the schedule line) for a day that falls on a non-working date according to the factory calendar of the unloading point. When this situation happen, the user will receive a warning (Message no. V1019) informing that the requested date is during a non-working time.

In the example above, user will choose a Requested Delivery date for a Sunday, that according to the calendar of his unloading point, is a non-working date. In this case, the user will receive the following warning message:

"No goods accepted on &1. The next possible date is: &2"

System will not propose a next date because it keeps open the possibility that customer will accept the delivery on a non-working day. This is the standard behavior. This can be checked on the attached note 1579665: "You 'only' get a warning message because the system wants to keep the possibility that you confirm this date despite the warning message. It is possible that the goods are very important for the customer and so the customer is disposed to accept a delivery on a non-working day".

When the user hits enter, he will bypass this warning, telling system that he accepts this goods to be delivered to a non-working date.

To summarize this, the user have two options that he can follow after message number V1019:

1) He can acknowledge the warning and accept that it is his intention to enter a non-working day by pressing "Enter".
2) After reading the warning, the user realize that he do not want to create an order with this delivery date and then he can manually change the Requested Delivery Date (or the first date field on the schedule line).

Section #2 Operations

Availability Check in Shipping

When we create the delivery for a sales order, the sales order requirement is reduced by the delivery quantity.
We can define whether delivery requirements are managed as individual or collective requirements.

If a material is not available for delivery by the material availability date, the system enters a delivery quantity of zero in the delivery.
The item is only included in the delivery if the quantity zero is permitted for the item category.

Blocking Confirmation

Specify that certain delivery blocks in the sales document header also block the confirmation of order quantities.

If, for example, we enter a delivery block in the sales order header and the order quantities can be confirmed within the deferral period specified, the system adds the deferral period to the current date, thus determining a material staging date. The requirements can, however, be passed on.

Fixing Quantities and Dates in Sales Documents

If the availability check for an item determines that the item cannot be delivered fully on the requested delivery date, and, as a result, one or more schedule lines have to be created for later delivery dates, the customer can decide whether to accept these delivery dates and quantities.

We can record the customer's decision either by setting an indicator in the Fixed date. The system then transfers the requirements for the schedule lines to material requirements planning.

During rescheduling, the fixed quantities and dates are no longer taken into account.

If the customer requires the goods earlier than the date that the system can confirm after the availability check, leave the Fixed date and qty field blank. The system only confirms the sales order once the entire order quantity can be delivered on the requested delivery date.

Reactions to the Availability Check in Sales Documents

Transaction OVZJ settings. The setting in OVZJ just applies for sales orders, quoations, inquiries, scheduling agreements and not for other document types e.g. deliveries, planned or production orders.

" - Dialog box in the case of shortages (batch/BAPI full dlv.)

Running an ATP check in the foreground (e.g. VA01/VA02) will trigger the delivery proposal screen only if the requested quantity could not be fully confirmed or the requested delivery date could not be met. For batch processes (e.g. background jobs like BOP the system will only accept full delivery confirmations (please check the section "full delivery").

"A" - One-time delivery

With that setting, we basically restrict the system to confirm the requested quantity in one schedule line. The confirmation can be on the original requested delivery date or on the new requested delivery date which is getting calculated by scheduling - in case the MBDAT is in the past. The confirmed quantity can be a partial or full confirmation.

"B" - Full delivery

Full delivery means that the customer just accepts a full confirmation or nothing. The system checks if the complete requested quantity is available. If not, the system returns a confirmed quantity of zero. The confirmation date does not matter in that case - it can be the requested delivery date or delayed confirmation date someday in the future.

"C" - Delivery proposal

The system will always use the "delivery proposal" result as confirmation. As a result the system will return the next possible confirmation - this confirmation might be a split of the requested quantity in several confirmation lines with different confirmed quantities and dates.

"D" - Dialog box in case of shortages (batch/BAPI one-time dlv)

Running an ATP check in the foreground (e.g. VA01/VA02) will trigger the delivery proposal screen only if the requested quantity could not be fully confirmed or the requested delivery date could not be met. For batch processes (e.g. background jobs like BOP the system will accept one-time delivery confirmations (please check section "one time delivery").

"E" - Dialog box in case of shortages (batch/BAPI dlv. prpsl)

Running an ATP check in the foreground (e.g. VA01/VA02) will trigger the delivery proposal screen only if the requested quantity could not be fully confirmed or the requested delivery date could not be met. For batch processes (e.g. background jobs like BOP the system will accept delivery proposal confirmations (please check section "delivery proposal").

In the case of the background processing, the rule is substituted ( source MV45AF0T_TRANSAKTION_INIT_FUNC/TRANSAKTION_INIT_FUNCTION):

' ' -> B
'D' -> 'A'
'E" -> 'C'

For stock transport orders the same setting can be found in the purchasing customizing.

Complete delivery defined for each sales order?

Indicates whether a sales order must be delivered completely in a single delivery or whether the order can be partially delivered and completed over a number of deliveries.

How to use Co09?

Selection screen
The checking rule is very important. For different checking rules, we will receive different results. The checking group from the material master and the checking rule define the scope of the check (customizing transaction OVZ9). In the scope of a check, we determine among others which receipts and issues should be considered. So a different scope of a check will lead to a different result in transaction Co09.

The checking rule in the area of sales and distribution and logistics execution is hardcoded. It can only be changed by modification. Sales documents are checked with checking rule 'A' and shipping documents with checking rule 'B'. In the area of production planning (PP) and material management (MM) we can define the own checking rules.

If we are using special stocks we have to add the special stock indicator to the checking rule. So when we are e.g. working with special customer stocks then we have to add 'E'. The checking rule for sales orders is 'AE' in this case. Furthermore, we also have to fill the special stock element (sales order, WBS element, sold-to-party) in order to get meaningful results.

The flag ' With reqmts.quants' in only relevant when the accumulation in transaction OVZ2 is set to the value '2' or '3'. Please consider the F1-help for the field 'Accumul' in transaction OVZ2 in order to understand how accumulation works.

Reading results

In the section 'Totals display' we can see the total amounts of 'Receipts' (stock is included), 'Issues', and 'Confrmd issues'.
The lines in blue correspond to the different levels on which the ATP check is carried out.
We have four levels (plant, storage location, batch, batch/storage location).

When the levels are maintained in the document then we will see the document on different levels and the atp check is carried out on those levels. E.g in the delivery 0080017249 the plant and the storage location is maintained. Therefore we can see it on both levels. The production order 000060003745 and the planned order 0000037719 are not maintained for a specific storage location therefore they can be only seen on plant level. For further information how the ATP check works please check SAP note 1513607 point 4.

Cumulated ATP quantity calculation cum. ATP qty will always show the maximum qty that could be confirmed on this date if a simulated requirement was entered on this line.
The cum. ATP qty will be increased on the date of a receipt if the receipt is greater than the issues below it (until the next receipt).
The cumulative ATP qty cannot be greater than the figure for Total receipts - Total Confirmed Issues.

Technical side
Transaction Co09 reads the relevant documents from the database or from the ATP buffer (ATP server is set up according to SAP note 99999 using function module STOCK_RECEIPT_ISSUE_READ. Locked ATP quantities that we can see in transaction SM12 in table ATPENQ are not read from CO09. There is no user exit available in this area.

Section #3 Additional process

Availability Across Plants

We can display the availability situation in the various plants for which material is maintained. We can select a plant with sufficient quantity for confirmation to be copied automatically into the Overview screen. Select the appropriate line and select Edit >Copy plant.

Using the user exit USEREXIT_PLANT_SELECTION in the Include RV03VFZZ we can make a preselection of the allowed plants. If we use this option, the Plant selection dialog box does not appear and the availability check is performed immediately for the allowed plant.

Availability check during credit block release

The confirmed quantities are usually reset when a credit block occurs for a sales document. This means a new availability check is triggered for the entire document when it is released from the credit block.
During the recheck, the system carries out an availability check before it runs the credit check, so the currently confirmed quantities are available for the credit limit check.
If we want the system to behave differently from the standard logic, we can use the user exit USEREXIT_AVAIL_CHECK_CREDIT in the include MV45AFZF. With the user exit we can:

The user exit is processed for each item. When a recheck takes place, the availability check is carried out before the credit check. Therefore, the new credit status is not yet available.

The 'Next date' (VBAK-CMNGV) can be changed. This is used for
The sales order header, this field specifies the next planned delivery date.
In the delivery header, the field specifies the next planned picking or goods issue date.
Using these dates in the headers of sales documents and deliveries, the system is able to recognize those documents for which processing time is critical.

Specifying Fixed Date and Quantity

The rule for transferring the results of the availability check determines how the system reacts for a specific sales area if the availability check determines that there is not enough stock for the order quantity.

If there is not enough stock, the system may react in two ways:
The system displays a dialog box and prompts us to choose between different options.
The system automatically proposes an option (it does not display a dialog box). This may be specified in transaction OVZJ and is used in the local ATP.
Alternative-based-confirmation (ABC)
ABC is a functionality similar to plant substitution of SAP APO – global ATP (GATP) i.e if the material is not available in the sales order plant, then the system automatically looks for its availability in other plants.
FULL_CONFIRMATION : The plant which can confirm the requested quantity , then that plant is the valid alternative
MAX_EARLIER_CONFIRMATION : The plant which can confirm the maximum of the requested quantity is the valid alternative
ON_TIME_CONFIRMATION: The plant which can confirm the maximum quantity of the requested order quantity on the requested delivery date is the valid alternative.
ATP in production

Availability Check for Components in the Production order

Transaction OPJK.
Availability Check for Components in the Planned Orde

Prerequisites
You have assigned a checking group to the materials to be checked in the material master ( MRP 3 view, Availability check field) must be firmed so that the reserved component quantities are not lost.
You have set a checking rule for the plant in Customizing for MRP in Maintain all plant parameters . You can also assign a checking rule directly to the material using the MRP group.

You can carry out the availability check
for a single planned order
as a Collective Availability Check for a selection of planned orders.
You carry out the collective availability check (Transaction MDVP or via the order information system) for planned orders.

Please check the component availability can also be checked according to the full commitment logic as an alternative. This can be activated in the Customizing of the MRP group (Transaction OPPR -> Availability check). Here, the respectively available quantity is reserved for all components. Consequently, it is possible that the order header is confirmed with the quantity 0 (since a component with the quantity 0 is available), however, other components are reserved. In this case, the planned order must be firmed so that the reserved component quantities are not lost.
You can choose between two types of availability check:
Availability Check According to ATP Logic
Availability Check Against Planned Independent Requirements
In the check against planned independent requirements, the system only checks the dependent requirement quantities against the open planned independent requirements created for the components. Therefore, neither the ATP quantity nor the receipts or stocks are included in this availability check
This type of availability check is most useful:
if assembly planning (in the standard system, planning strategy 70) or phantom assembly planning (in the standard system, planning strategy 59) is used to plan the components
if the availability situation is required at short notice and the results from this check are precise enough.

You can switch off the availability check for certain materials. This is especially useful for materials that you know are always available in stock, such as screws. To make sure that these materials are not included in the check, you can set the indicator No check in the material master (view MRP 3 ) in the field Availability check.

ATP sequencing
MDVP
MDVP RLD05000 Collective Availability Check PAUF
You can check whether the quantity available for components in the planned order is sufficient to produce the planned order quantity on time.

You can carry out the availability check
·        for a single planned order
·        as a Collective Availability Check for a selection of planned orders.

You can choose between two types of availability check:
·        Availability Check According to ATP Logic
o   In the check according to ATP logic, the system checks whether the dependent requirements of each component in a planned order are covered by specific receipt and issue elements or by stock.
o   In Customizing for MRP under Define availability check for components   MRP group,   you have determined whether the ATP check is to per MRP group following the logic of full or partial confirmation
·        Availability Check Against Planned Independent Requirements .
o   In the check against planned independent requirements, the system only checks the dependent requirement quantities against the open planned independent requirements created for the components. Therefore, neither the ATP quantity nor the receipts or stocks are included in this availability check.
o   if assembly planning (in the standard system, planning strategy 70) or phantom assembly planning (in the standard system, planning strategy 59) is used to plan the components
o   if the availability situation is required at short notice and the results from this check are precise enough.

You can see the type of availability check that was last carried out in the header of the planned order in the field entitled, Type of AvC.

Resetting the Availability Check
To reset the results of the availability check and thus the confirmation on dependent requirements level, proceed as follows:

In the header of the planned order, select, Edit Reset component availability.

The system then resets the Confirmed quantity and the Order confirmation date for the dependent requirements.
Collective Availability Check for Components in Planned Orders
In the collective availability check you can check whether the components required are available for several planned orders simultaneously. This is particularly useful if you want to convert several planned orders simultaneously, for example, and you want to check beforehand if and by when the components are available.

·        To be able to carry out the collective availability check, you need a profile order view. In the standard system the profile order view 000001 is used. The profile controls the formatting of the overview list with the planned orders selected (field selection, field sequence).
·        For the missing parts/component list, a profile is also used in the standard system: profile component view 000001. The profile component view controls the formatting of the component list (field selection, field sequence).

·        You can create your own profile in Customizing for MRP, under Carry out collective availability check, or you can copy and change the profile 000001.

Check Mode for Collective Availability Check

Resetting the availability data

The following data of all selected planned orders can be deleted before the check is carried out:

1.      confirmed quantity in the material components

2.      the total confirmation date in the planned order header

3.      the confirmed quantity in the planned order header

Checking availability

·        If you select Individual , the availability is checked for each material, depending on the settings in the check group. If the check group is set, for example, so that the material is always checked against planned independent requirements, then this check is carried out.

·        If you select ATP, the availability check is an ATP check for all materials, independent of the settings in the check group.

·        If you select Forecast check , the availability check is against planned independent requirements for all materials. However, you cannot use this check if you have defined No check against planned independent requirements.

Firming

·        You can define that the planned orders, for which there are components available, are firmed after the availability check. This is also possible if the planned orders cannot be fully confirmed.

·        Firmed planned orders can no longer be changed by the planning run. In addition, the components are also firmed, that is the BOM is not exploded again in the next planning run.
COMAC

11810 - ATP confmd qntits f.pland order,sbcon.PR,sbcon.odr
An availability check is carried out in the planned order or subcontracting purchase requisition or subcontract order on the item overview of the component processing. The system displays all components with confirmed quantity = 0 in the results list of the availability check, although sufficient stock is available on component level.
At least one component has indeed a missing availibility.
The collective availability check MDVP reports all components as missing parts although only individual components are not available.

ATP in Inventory Management and Physical Inventory
There are two types of availability check:
Availability check for the various stock types in Inventory Management
Check for the available stocks in Materials Planning (MRP)
In Customizing for MRP in the IMG activity Availability of Stock in Transfer/Blocked Stock/ Restricted Stock , determine whether stock in transfer, blocked stock and restricted-use stock are included in the plant.
Availability check of the stock types is carried out automatically and cannot be manually set in the system. Non-availability results in an error message.

In Customizing for Inventory Management, you can configure the dynamic availability check for goods movements. In the step Define Checking Rule , you determine for each checking rule which stocks, receipts, and issues should be included in the availability overview (transaction code CO09).

For every material movement, the system automatically performs an availability check of the stock types if this has been defined for a material. The availability check prevents the book inventory balance of the various physical stock types (for example, unrestricted-use stock) from becoming negative.

Different stocks are checked, depending on the movement type:
In the case of a withdrawal for consumption, unrestricted-use stock is checked.
In the case of a release from stock in quality inspection, quality inspection stock is checked.
In the case of consumption of consignment material, consignment stock for unrestricted use is checked.
T-code  omcm

Section #4 Additional information

FAQ

3004240 - Availability check despite enabled delivery date and quantity fixed indicator

Delivery date and confirmed quantity will be re-determined by the system unexpectedly when releasing a sales order in transaction VKM3. This happens despite the enabled delivery date and quantity fixed indicator (VBAP-FIXMG) feature.

Availability check is carried out in a sales order item
Before the confirmation of the delivery quantity and the delivery date confirmed, the "Fixed quantity/date" indicator (VBAP-FIXMG) is set manually, it is transferred correctly to the schedule lines.
After saving the sales order and use VKM3 or VKM4 to release the credit limit check, the system calls the availability check again in the background and the schedule lines are reset or rescheduled even though the quantity and date were fixed.

With the "Fixed date and quantity" indicator (VBAP-FIXMG) the confirmed quantities and dates can be discussed and fixed with the customer, so that if the goods become available earlier, the confirmed date will not change.

The item is then confirmed again. The "Fixed date and quantity" indicator means that an automatic availability check is not carried out externally (for example, in the context of rescheduling or backorder processing).

However, active action, such as an ATP-relevant change in transaction VA02 or credit release of the document, does not prevent the availability check, as this can lead to inconsistencies. In particular, credit release is very critical. For credit-blocked documents, the confirmed quantity is usually set to zero.

If the availability check is not carried out during the credit release, the confirmed quantity would always remain at zero. This does not make sense from a business point of view, since this item can never be confirmed again as long as the indicator is active. However, the indicator is used to fix the confirmations. For this reason, the availability check should always be carried out during the credit release.

What is important here is that a credit block usually resets the confirmed quantity, but does not automatically delete the requirements. The "Fixed date and quantity" indicator can be used to transfer confirmed quantities to planning and thus delete the requirements.

547508 - FAQ: Schedule line overview and ATP

What is the effect of the 'Fixed date and quantity' indicator?

Answer:
1. A fixed item creates only one requirement for the amount of the confirmed quantity. If it is not available, the system issues a message indicating that the customer requires complete delivery (item XXX is not confirmed).This indicator is identical to the "Fix qty/date" indicator on the availability control screen.However, you can manually check and change a fixed item.
2. The corresponding item is not taken into account during rescheduling (V_V2).

1324433 - Availability check during credit block release

You release a sales document from a credit block.
You carry out a recheck for a sales document (in the background using report RVKRED09 or in a credit list, for example using transaction VKM1).

This triggers the availability check (ATP) for the entire document. You cannot tell which items are included in the availability check.

A decision regarding whether to perform the availability check is made for each item.

The item does not have any confirmed quantities (VBAP-KBMENG = 0).-> The availability check is performed.
The item is confirmed either wholly or partially (VBAP-KBMENG > 0).-> The availability check is not performed.
The item is partially delivered and the confirmed quantity is higher than the delivered quantity (confirmed quantity - delivered quantity = 0).-> The availability check is performed.
The system carries out a product selection for the item.-> The availability check is performed.
The item belongs to a scheduling agreement with releases (component supplier).-> The availability check is performed.

If you want your system to behave differently from the standard logic, you can use the user exit USEREXIT_AVAIL_CHECK_CREDIT in the include MV45AFZF. With the user exit you can:

... Execute the availability check in all scenarios.
... Call the availability check in accordance with the standard logic, as described above (the default setting).
... Skip the availability check.

The user exit is processed for each item which means a decision can be made for each item.

When a recheck takes place, the availability check is carried out before the credit check. Therefore, the new credit status is not yet available in USEREXIT_AVAIL_CHECK_CREDIT.

2928307 - subcontracting stock not considered for batches and storage locations

This happens when there is a storage location or batch specified for the subcontracting component in the production order. Up to now, the batches stored in the subcontracting segment (table MSLB) were not considered by the ATP check. They also do not contain any storage location information. In the same way, the subcontracting stock in table MSSL does not contain any storage location information. Therefore, it can make sense to tick the checkbox "No storage location inspection" in the ATP scope of check (tcode ovz9) when performing an ATP check.

Implement the following program corrections. The note will address the following problem: consideration of the batch stored in the subcontracting segment (table MSLB). In addition, if it is not possible to tick "No storage location inspection" in the ATP scope of check (tcode ovz9), the note offers an optional possibility to allow the ATP check to confirm the requested quantities. This is achieved by doing the following:

Enter the following parameter in transaction stvarv:
Parameter: ATP_VENDOR_STOCK_LGORT
Value : X

After enabling this parameter, the system will allow the ATP check to add the subcontracting stock from table MSSL to the existing storage location stock for every storage location of the plant (as it is not possible to determine to which storage location the stock should be added). The system will do similar work for the subcontracting stock at batch level from table MSLB. It will allow the ATP check to add it to the existing stock at batch/storage location level for every storage location of the plant.

547512 - FAQ: Customizing for ATP in R/3

I activated the quantity block (=soft block). Why are other users still not able to access the material?

If the material block (hard block, OVZ1) and the quantity block (soft block, OVZ2) are set in Customizing, only the quantity block is active. During the actual calculation, however, the system sets a material block for several milliseconds and deletes it again. You do not normally notice this, however, during an EDI import, this can lead to lock situations. This is a design requirement and cannot be avoided.

Why are stock transfer quantities not used for the confirmation although I set this in the scope of check (OVZ9)?

The "Stock in transfer" field (T441V-UMLMP) only affects quantities that are moved during a stock transfer in the two-step procedure (for example movement type 313 or 303) and not quantities that are transferred by means of stock transfer orders.

How can I just check at storage location level? The quantities (ATP situation) at plant level should not be taken into account.

:1) In ERP, you can keep the ATP separately over an MRP area. You cannot set this in the ATP controller. For this reason, the material must be moved to a storage location that can be scheduled separately (mm02 -> MRP1 and MRP4 view).
2) In S/4HANA, the method using the MRP area is the only one possible. You cannot set this in the ATP controller. For this reason, the material must be moved to a storage location that can be scheduled separately (mm02 -> MRP1 view).

I use product selection and the relevant materials have available quantity. Why does the system not confirm anything?

In the product selection, the system only allows a one-time delivery for the desired date as a result (similar to OVZJ, rule for the transfer of the result, setting A). If quantity is available at a later date, this result is not accepted.

Why is "Cumulation of requirement quantity" not supported when creating AND changing an SD order?

As a result of this kind of cumulation, some orders may never be confirmed.

Example:

for a scarce material that is in stock with 100 pcs,
a "large" order of more than 500 pcs is entered and confirmed with a quantity of 0 pcs.
If further "small" orders were entered or a rescheduling was carried out, none of the small orders could ever be confirmed due to the one large order,
since the requirement quantity of 500 pcs would be considered instead of the confirmed quantity of, for example, 0 pcs.
Even in change mode, nothing could be confirmed due to an order that could only be completely confirmed at a much later date after production or procurement, because of its size.

What effect does a check without cumulation have?

Answer:If the cumulation (OVZ2) is switched off, a requirement can be confirmed against the next possible requirements element (for example, inward movement). However, if the inward movement is postponed, for example, this results in an overconfirmation if a further requirement was confirmed against this inward movement previously.
When you call the Availability Overview (CO09), you cannot set the "With reqmts quants" field if the cumulation is switched off for the materials checking group.

Why does the delivery not check ATP although the ATP is activated at the item category?

The system can only check ATP if the ATP is activated at the delivery item category (OVLP) AND if the system finds a movement type.

Why is the delivery agreement schedule line not confirmed even though it was created without errors using IDoc and the materials are available in sufficient quantity?

Check your customizing settings. If the exclusive material block is active in Check Criteria (OVZ1) but the quantity block is not active in Checking Group (OVZ2), and if the material block was set when the IDoc was imported in a parallel session, the system behaves as follows: No availability check can be carried out. An information message is created and the IDoc import is completed with status 53 (without errors). Therefore, you should set the quantity block (OVZ2).

I use material substitution in the sales order, with the same material in the main item and the subitem. Why is the subitem not confirmed when I create the delivery even though there is sufficient stock?

In the material master, view "Materials Planning 3", a strategy group was entered. This allows a corresponding requirements class to be found. For the item type of the main item (default TAX), in view "Assignment of requirements type to action" (Transaction OVZI), only field "Q" (source) with value 1 "Item type and materials planning characteristic" may be filled in this case. All other fields must be blank to prevent the main item from being relevant for requirements and to allow the subitem to be confirmed.

Question: Can I perform an ATP check in subcontracting provision stock only?

A check in the subcontractor provision stock only can only be performed by using an MRP area for the subcontractor. If you do not use MRP areas, you can only select whether the subcontractor provision stock is to be selected as available stock in Customizing of the scope of check.

ATP inconsistencies

In the area of ATP check, inconsistent sales or delivery requirements, as well as obsolete lock entries can cause serious problems, for instance:
• A sales document cannot be confirmed although it seems there is enough available quantity.
• A delivery cannot be created despite of having enough stock. Error message VL367 (An item with no delivery quantity is not permitted. Item will be deleted.) and VL150 (Only & & of material & & available) is raised.
• Completed sales documents or deliveries can be found in transaction MD04, CO06 or CO09.

In order to find out whether there are inconsistent / obsolete entries in your system, please go through the below mentioned steps.

STEP 1 – look for inconsistent sales / delivery requirements

Requirements of sales documents and deliveries are stored in the table VBBE (when single requirements are used) and VBBS (when total requirements are used). Sometimes it happens that already completed requirements have not been deleted from these tables. These inconsistencies can be corrected by using the report SDRQCR21.
In order to run the report in simulation mode, you have to select the ‘Comparison’ flag only.

With this flag being set, the potential changes will not be written to the database. This option can be very useful when you only want to check whether there are inconsistent entries on your system.
In order to check AND correct the inconsistencies, you have to select the ‘Data transfer’ flag.

In order to improve the performance of the program, the flag 'Comparison' should be set too. This way the report corrects only the affected requirements. If this parameter is not set, the report will completely restructure the database for the selected material(s) and plant(s).

For more information on the report, please check SAP Note 25444 - SDRQCR21: Recovery of sales and delivery requirements and SAP Note 998102 - SDRQCR21: Enhancements to support the check w/ locked docs, these documents provide all the necessary information on how the report should be used and what are the available settings.

STEP 2 – look for obsolete lock entries in table ATPENQ

If the soft block is activated in transaction OVZ2, the system writes ATP data in an enqueue record into the enqueue table on the enqueue server. In a parallel session an ATP check reads these records and takes them into account. This way parallel processing of the same material is possible and the ATP check gives meaningful results. This enqueue record will be deleted when the document is saved. In rare cases it could happen that the enqueue record is not deleted and it blocks the available quantity. An indication for a remaining lock entry in table ATPENQ is that you cannot see the record in transaction CO09 but you can see the record when you carry out a new ATP check in a sales order and on the availability control screen you press the button 'ATP quantities'. You can also see the record in transaction SM12 selecting table ATPENQ. There you can see the time when the lock entry has been created as well as the material, plant, the document and the item number. Obsolete records must be deleted manually directly from transaction SM12.

In order to analyze why obsolete lock entries remain in table ATPENQ, SAP Product Support needs a reproducible example, this is the only way to analyze what is happening on code level.

STEP 3 – look for obsolete lock entries in table LATP_ENQ

If you are using CRM, the document itself is not replicated to the ERP system just yet, not even if ATP check is carried out in the ERP system. In this case the system writes a lock entry into table LATP_ENQ. You can check the records of the table in transaction SE16. Obsolete records can prevent the confirmation of further requirements from sales or delivery documents, so these obsolete records have to be deleted manually. For further information, please check SAP Note 682613 - FAQ: Local ATP from CRM .

STEP 4 – look for inconsistencies in the ATP Buffer

If the ATP server is being used, a discrepancy between the data in the ATP buffer and the database can lead to wrong results during an availability check. In order to resolve this problem the ATP buffer needs to be refreshed.

For more information on the ATP server, please consider SAP Note 99999 - ATP server: Installation and sizing and SAP Note 163819 - ATP: Transaction ACBD.

2651341 - FAQ ATP_VBBE_CONSISTENCY report

There are too many, too few or simply incorrect sales document (quotation, sales order, scheduling agreement) or delivery requirements. You can detect or check this using Transaction MD04 (Stock/Requirements List). These inconsistencies may trigger follow-on errors in planning, procurement

(production, purchase order) or document processing (availability check).

This report is a technical job to ensure consistency in the aggregate table VBBE (open quantities/planning relevant in sales documents). It is a successor of the report SDRQCR21, but with improved performance, adjusted for S/4 scope, a log persistence on database (table: VBBE_LOG) and dynamic packaging (on material and/or plant), if select options for material or plant are not used.

The table "VBBE_LOG" contains the log and shows which orders have been corrected by the report. This log was considered/developed just for the development/support engineers.
Please check transaction SJOBREPO and search for a job definition with "ATP_VBBE_CONSISTENCY_JOB".
The report can be scheduled to run on a daily basis (preferable during night times) to find and correct VBBE inconsistencies. Verify the job log or the table VBBE_LOG for reoccurring entries.

How to keep the confirmed quantity when the sales order is credit blocked?

The deletion of the confirmed quantities in credit-blocked sales orders is implemented by means of requirements. Requirement 101 in transaction OVB8 makes that confirmed quantities are set to zero if the credit block is set.

Why Sales order is not getting confirmed before and after block (VKM1/3)?

The confirmed qty. can be nullified if a sales document has the delivery block or the credit check is failed.

Situation: After the credit release of a blocked order using VKM3, the confirmed quantity in the sales order is not updated, i.e. no automatic ATP after releasing. If the availability checking rule is blank, when the system performs the availability check during credit release, the system will choose full delivery. If the quantity required cannot be confirmed fully the system will confirm zero.

Solution: Run transaction OVZJ to find the corresponding sales area and set the Avail. check rule to E.

'Final Delivery' and 'Delivery Completed' in ATP with STOs

The 'Final Delivery' indicator has an effect on the issuing side. With this flag, we tell the system we will not create any more deliveries for the STO (stock transport order). The requirement of the STO will vanish from transaction Co09. This means that an ATP check on the issuing side will not consider the STO as a requirement anymore. The indicator has no effect on the receiving side. On the receiving side, we still can see the STO in transaction Co09, and therefore it is also considered as receipt element during the availability check of a requirement.
The indicator only means that no further delivery will be created. But we still can have an unprocessed delivery in the pipeline for which we will post GI (goods issue) in the issuing plant and then posting GR (goods receipt) in the receiving plant.
The STO will vanish in transaction Co09 when setting the 'Delivery Completed' indicator. After having set the indicator the availability check will not consider the STO as a receipt element anymore. The delivery process is completed, we will not process any GR for the STO any more

Available quantity of 9,999,999,999

For an availability check that takes the replenishment lead dime into account, any quantity can be confirmed after the replenishment lead time has expired. This means that the "Check without RLT" indicator must be set in the "Replenishment lead time" field for the check.

Material Block

If the material block (hard block, OVZ1) and the quantity block (soft block, OVZ2) are set in Customizing, only the quantity block is active. During the actual calculation, however, the system sets a material block for several milliseconds and deletes it again. We do not normally notice this, however, during an EDI import, this can lead to lock situations. This is a design requirement and cannot be avoided.

Delivery block on sched.line level and requirements?

A delivery block on schedule line level (VBEP-LIFSP) does not delete the confirmed quantity after we save even though the "Confirmation block" (TVLS-SPEBE) is set for the blocking reason.
It is because the confirmation block is only effective for the entire order, which is on the header level.

2799290 - Stock can be issued out although it is reserved

Activate the dynamic availability check and include reservation in checking rule customizing.
More details, check the IMG activitiy documentation of SPRO path:
->Materials Management
-> Inventory Management and Physical Inventory
-> Goods Issue / Transfer Postings
-> Set Dynamic Availability Check

2920200 - Why availability check is not working as expected in Inventory Management (MM-IM)?

The availability check is not completely or correctly set up.

As one of the two pre-requisites for ATP check setup, a checking group for the availability check must be maintained in material master, 'MRP 3' tab.
The checking group is also used in SD area and can be maintained as well in material master, 'Sales: General/Plant Data' tab.

Another pre-requisite is to complete the setting(movement type, checking rule, define checking rule and transaction code) in MM-IM customizing.

For goods issue/transfer posting, go to transaction OMCP.
For goods receipt, go to transaction OMCM.
For reservation, go to transaction OMB1.

NOTE: all the steps are required, if any step is missed/skipped, the ATP will not be working correctly.

Among all the required steps, 'define checking rule' is the key to decide how ATP check should work.

The ATP check is carried out in function module AVAILABILITY_CHECK_CONTROLLER based on the settings in below screenshot, for example, in the 'Requirement' segment, ticking the corresponding indicator means that if there is open document that has not been completed or quantity has not been fully confirmed, the open quantity will 'hold' the same quantity of current available stock and this part of the stock will be excluded during ATP check because it is reserved for the open document and cannot be used for other processes.

To check available stock per checking rule, CO09 can be used or set a breakpoint at FM AVAILABILITY_CHECK_CONTROLLER and see how P_ATPCSX[] is determined.

Section 5: Enhancements

BADI-s

BAdI: Enhancement of Rescheduling Functions
BAdI: Selection of Sales Documents for Rescheduling
Implementation: Alternative Selection for Recovering Requirements
BAdI: Deletion of Delivery Groups in SD Documents
BAdI: Adjustment of Data Transferred to ATP Check

User exits in Product Allocation

SDQUX003 EXIT_SAPLQUOT_003 User-Exit : SD Product allocation, extended checks (ATP)
SDQUX004 EXIT_SAPLQUOT_004 Product Allocations: Change the Product Allocation Steps
SDQUX005 EXIT_SAPLQUOT_005 Product Allocations: Adjust product allocation quantities
In program FV45VFZY form USEREXIT_QUOTA_KEY_VALUE additional characteristics can be filled which cannot be filled automatically from the communication structures.

Engine (ATP calculation)

CALL FUNCTION 'STOCK_RECEIPT_ISSUE_READ'

atpkxs
atpkxr
atpkxi

#DELKZ MRP element indicator with the list of values:

AR Dependent reservation
BA Purchase requisition
BB Subcontractor requirements of the material provided
BE Order item schedule line
BP Gross requirements planning
BR Process order
CH Batch stock
ER End of replenishment lead time
E1 Subcontracting purchasing
FE Production order
FH End of planning time fence
IH Maintenance order
JI JIT call
IM Actual goods receipt quantity
IW In plant (only relevant for IS Automotive)
KB Individual customer stock
KD Customer independent requirement (currently not used)
KK Consignment stock for customer (availability check)
LA Shipping notification
LB Storage location stock
LC Batch/storage location stock
LE SA schedule line
LF JIT delivery schedule
LK Stock with subcontractor
LL Forecast delivery schedule
MB Goods issue
MR Reservation
MS Direct production
NE Network order
PA Planned order
PB Project stock
PP Planned independent requirement
PR Forecast requirement
QM Inspection lot for quality management
RP Returns item
RR MRP requirement (only relevant for IS-Automotive)
RU Confirmation
S2 Simulated requirement from availability check
SA Simulation order
SB Dependent requirement
SF Safety requirement
SH Safety stock
SI Simulation requirement
SM Sim. dependent reqmts
SU Total requirements
TB Transfer requirements WMS
U1 Release order for a stock transfer order
U2 Release order for a stock transfer requisition
U3 Transfer requirement for simulation order
U4 Release order for stock transport scheduling agreement
UB Unplanned requirement
UL Reservation in another plant
UR Stock transfer reservation
VA Request for quotation
VB Quotation
VC Order
VE SD scheduling agreement
VF SD scheduling agreement; external service agent
VG Contract
VH Returns from Consignation Stock at Customer
VI Delivery Free of Charge
VJ Delivery
VP Planning
VT Returns (availability check)
VW External sales order
VZ Unverified delivery
WA Goods issue
WB Plant stock
WE Goods receipt
WH End replenishment period
DD Effective-out date
C3 Subcontr. Customer Order Stock
C4 Subcontr. Project Stock
HS SegmentBatchStock
LS SegmentSLocStock
CS SegmentBatchSLoc
WS SegmentStock

User exits

User Exits in the ATP

In Program FV45VFZZ

USEREXIT_ADD_FIELD_TO_HEADER
USEREXIT_ADD_FIELD_TO_LINE

In Program FV45VFZY

USEREXIT_DELIVERY_GROUPS
USEREXIT_MVERF_INIT
USEREXIT_QUOTA_KEY_VALUE

In Program RV03VFZZ

USEREXIT_AVAILABILITY_IN
USEREXIT_AVAILABILITY_OUT
USEREXIT_DARA_REFRESH
USEREXIT_PLANT_SELECTION

User Exits in SD

MV45AFZA FORM USEREXIT_REFRESH_DOCUMENT
MV45AFZB FORM USEREXIT_CHECK_VBAK
MV45AFZC FORM USEREXIT_CHECK_VBLB-USR05
MV45AFZD FORM USEREXIT_CONFIG_DATE_EXPLOSION
MV45AFZF FORM USEREXIT_AVAIL_CHECK_CREDIT
MV45AFZH FORM AUTHORIZATION_VALUE_SPLIT
MV45AFZZ FORM USEREXIT_MOVE_FIELD_TO_VBAK Eg add customer master fields to the sales document
MV45AFZZ FORM USEREXIT_MOVE_FIELD_TO_VBAP Eg add material master fields to the sales document
MV45AFZZ FORM USEREXIT_SAVE_DOCUMENT

References

1324433 - Availability check during credit block release
ATP customizing
1604270 - ATP confirms stock regardless of the stock situation
1644443 - Documentation on User Exits in Availability check

The following user-exits are available:

User-Exits in the include RV03VFZZ (called in Form MVERF_PRUEFEN)
User-Exits of the enhancement ATP00001 (called in Function Module AVAILABILITY_CHECK_CONTROLLER

On the one hand the result of the availability check depends on the input data which can be influenced in the exits USEREXIT_AVAILABILITY_IN (RV03VFZZ) and EXIT_SAPLATPC_001 (ATP00001). When you change e.g. the date then the result of the availability check could be totally different. Using inconsistent input data could lead to totally wrong results.

On the other hand you can change the result of the availability check in the user-exits USEREXIT_AVAILABILITY_OUT (RV03VFZZ) and EXIT_SAPLATPC_002 (ATP00001). So if you confirm in these exits more than ATP would confirm then you create inconsistencies. This is absolutely to be avoided!

ATP scope of the check
2604756 - ATP confirmation behavior - result mode explanation
622299 - Consulting: Availability check against planning

154682 - Availability check doesn't take batch into account (modification)

The availability check for stock transport orders (or stock transport requisitions, stock transport scheduling agreements) does not take account of a batch entered in the purchasing document. The system does not check against the stock of this batch in the supplying plant, but against the entire plant stock of the material.

The availability check is NOT triggered automatically if the batch is changed.

2769819 - BAPI MATERIAL AVAILABILITY Lead Time based on Planned Delivery Time

Reason: While running BAPI_MATERIAL_AVAIALABILITY

1. Planned delivery time is not considered while calculating ENDLEADTIME

2. Special procurement type not considered while determining procurement type.

Implement correction instruction.

2786800 - Wrong requirements date when scheduling via planned delivery time in a stock transfer scenario

The calculation of release dates via planned delivery time in a stock transfer scenario as described in SAP note 361308 does not work anymore in S/4HANA when displaying the stock/requirements list in the transaction MD04 with HANA_OFF or via BAPI_MATERIAL_STOCK_REQ_LIST.

1047256 - FAQ: requirements, reference documents and overconfirmations

1) When setting the reason for rejection for a sales order referencing a preceding document such as a quotation, the requirement for the preceding document is not increased by the rejected quantity (this is not true for MAIS scheduling agreements, the requirements of the scheduling agreement is increased after the reason for rejection is set in a referring sales order)
2) in transaction co09, one can see an overconfirmation after removing a reason for rejection, unsetting the partial delivery indicator or decreasing the value in the underdelivery tolerance

Solution
1)This is an intended behaviour: rejection is not regarded as cancellation (For sales orders, this can only be achieved by item deletion or quantity reduction). You may use the reason for rejection also as final delivery flag, ie if you want to give the overall delivery status (field VBUP-LFGSA) to "Completely delivered" to a sales order which is only partially delivered. For that reason too, it would not be relevant to increase the preceding document requirements.
2)This is because when you remove these indicators, an ATP check takes place and passes the preceding document quantity as a correction record. This is a current limitation of the system.
In order to remove the overconfirmation, you either have to add new receipts or if you can't, trigger an ATP check on the other documents (for instance the preceding document or one of the other standalone documents) and save the document. This ATP check will unconfirm the document which will in turn fix the overconfirmation situation.
In the case of the reason for rejection for a sales order referencing a quotation, please consider if you cannot use a delivery block instead of the reason for rejection. By using a delivery block which is customized (table TVLS) not to block confirmations, you can keep the requirement active and thus avoid overconfirmations.

2195518 - Everything about stock transport orders and ATP ( Version 4 from 09.03.2021)

If you want to execute an ATP check in the STO you have to maintain the following customizing:

a checking group in the material master (MRP 3 Tab) for the delivering plant

a checking rule for the document type and supplying plant (SPRO → IMG → Materials Management → Purchasing → Purchase Order → Set up Stock Transport Order → Assign Delivery Type and Checking Rule, field PRREG)

a valid scope of check for the checking group and checking rule (transaction OVZ9).

In transaction ME21N you can create a stock transport order. The availability will be checked on the material availability date for the supplying plant and -if you customized and maintained it- for the issuing storage location. You can find the relevant customizing under the path

SPRO → Materials Management → Purchasing → Purchase Order → Set up Stock Transport Order → Set up Stock Transfer Between Storage Locations → Assign Delivery Type and Checking Rule According to Storage Location

The result of the ATP check is displayed by fields MNG02 and DAT01 of table EKET. Field MNG02 shows the quantity which can be confirmed for the committed date (DAT01).

If the requested quantity can never be fully confirmed field DAT01 will show 31.12.9999. For more information please check SAP Note 2147744.

You can also set up automatic delivery creation for stock transport orders. Once the STO is created the outbound delivery is created automatically in the background. There is only one ATP check carried out, with the checking rule you assigned to the combination of the delivery type and supplying plant.

The two customizing settings are required to enable the automatic delivery creation:

X or Y auto delivery creation in SPRO → Materials Management → Purchasing → Purchase Order → Set up Stock Transport Order → Activate Automatic Delivery Creation and CRM Billing for the documenty type and supplying plant
X or Y auto delivery creation in SPRO → Materials Management → Purchasing → Purchase Order → Set up Stock Transport Order → Activate Automatic Delivery Creation for PO Type and Shipping Point

Important customizing settings for STOs:

'Incl. Purchase Orders' in the scope of check

The first highlighted field in the screenshot makes sure that the ATP check considers the purchase orders during an availability check. Depending on the value the ATP check takes the requested or the confirmed quantity, the requested delivery date or the confirmed delivery date into account. For more information please check SAP Note 766475.
The second highlighted setting is for requirements resulting from STOs or from stock transport requisitions. Please consider that if you include these requirements in the scope of check, CO09 will display the purchase order on the supplying side.

'ATP confirmations relevant for MRP' indicator

Depending on the configuration MD04 and CO09 can show different quantities and dates. The following table shows which quantity MD04 and CO09 display for the supplying plant according to the customizing settings. For example, if you customized field BESTP for 'X' in the scope of check and you flagged field ATPCONFMRP your stock transport order will be displayed in transactions MD04 and CO09 with the confirmed quantity and confirmed date.

'Rule for Adoption of ATP Results in Purchasing' field
'Perform Shipment Scheduling' and 'Use Route Schedule for Shipment Scheduling' indicators

You can also use route schedules by activating field MERFP. For the process flow of route schedules please check SAP Note 146829.

'Fix date and quantity' indicator
'Final delivery' and 'Delivery completed' indicators
If you set the 'Final delivery' indicator in the STO it has only an effect on the issuing side. The availability check and the CO09 of the receiving side will still consider the STO as a receipt element when checking the availability of requirements. To prevent this you can set the 'Delivery Completed' indicator. Please check the SAP Notes 1906272 and 1093582.
For the customizing of the returns please check SAP Notes 606282 and 634038.

For the supplying plant MD04 and CO09 shows the material staging date displayed in the STO.

In the standard system it is not possible to check against batches even though the batch is specified on item level. In function modul AVAILABILITY_CHECK_CONTROLLER field CHARG of standard table P_ATPCSX is simply not filled in contrast to WERKS (and LGORT eventually). For a modification that enables this functionality please check SAP Note 154682.