Availability Check
Availability Check (ATP - Available to Promise) in SAP SD determines whether requested delivery quantities and dates can be confirmed based on stock, planned receipts, and replenishment lead times. This topic covers the business purpose, configuration building blocks (checking groups, checking rules, scope of check), the runtime confirmation logic during order and delivery processing, integration with MM/PP, common production issues, and differences across ECC, S/4HANA on-premise, and S/4HANA public cloud including advanced ATP (aATP) concepts.
Overview
Availability Check (ATP - Available to Promise) in SAP SD determines whether requested delivery quantities and dates can be confirmed based on stock, planned receipts, and replenishment lead times. This topic covers the business purpose, configuration building blocks (checking groups, checking rules, scope of check), the runtime confirmation logic during order and delivery processing, integration with MM/PP, common production issues, and differences across ECC, S/4HANA on-premise, and S/4HANA public cloud including advanced ATP (aATP) concepts.
Lessons in this topic
- SD Availability Check Part 1: What ATP Does and Why It MattersThe business purpose of the availability check (ATP): promising reliable delivery dates, how requested and confirmed schedule lines arise, the ATP formula (stock + receipts − issues), backward and forward scheduling, and where ATP runs in the order-to-cash flow.
- SD Availability Check Part 2: Configuring the Classic Availability CheckConfigure the building blocks: checking groups (summarized or individual requirements, accumulation, blocking), checking rules, requirements types and classes, schedule line category flags, and availability check at plant versus storage location — the setup S/4HANA still uses as the base for aATP.
- SD Availability Check Part 3: Scope of Check and Replenishment Lead TimeDefine what ATP considers (OVZ9): stock types, receipts (POs, requisitions, planned and production orders), issues, checking horizon and replenishment lead time — and how these choices trade reliable promises against optimistic confirmations.
- SD Availability Check Part 10: Architecting Availability Check at Scale — Classic ATP, aATP and Landscape Trade-offsArchitect's view: segmenting materials by supply behavior, designing checking groups and scopes with supply chain, choosing which aATP functions to deploy, performance and volume, integration with EWM, TM and external planning (IBP), migration from classic ATP or APO GATP, and governance of priorities.
- SD Availability Check Part 4: Classic Backorder Processing and ReschedulingReassign confirmed quantities when supply is short or changes: manual backorder processing (V_RA), backorder lists, mass rescheduling (V_V2) and its sorting rules, simulation versus update, and the integration with MRP, deliveries and customer priorities.
- SD Availability Check Part 5: aATP Product Availability Check in S/4HANAWhat advanced ATP (aATP) changes in S/4HANA: the product availability check (PAC) as the core, still based on checking group, checking rule and scope of check, plus the additional functions product allocation, alternative-based confirmation, backorder processing and supply protection, with Fiori apps for monitoring.
- SD Availability Check Part 9: Troubleshooting ATP and aATPA method for "no confirmation" and "wrong date" incidents: verify whether ATP ran, scope of check and checking rule, replenishment lead time, scheduling dates, receipts and issues in CO09, allocation and supply protection limits, BOP changes, and delivery-time rechecks.
- SD Availability Check Part 6: Product Allocation in Advanced ATPUse product allocation to share constrained supply fairly: allocation objects and characteristics (customer, region, channel), periods and planned quantities, sequences combining several constraints, assignment to products and checks, consumption and monitoring — and when allocation is the wrong tool.
- SD Availability Check Part 7: Alternative-Based Confirmation — Plant and Product SubstitutionConfirm from alternatives when the requested plant or product cannot: alternative-based confirmation (ABC) strategies with alternative plants and products, sequencing and restrictions, sub-item creation, and the logistics, pricing and tax consequences that must be checked.
- SD Availability Check Part 8: aATP Backorder Processing — Segments, Strategies and ReconfirmationRun backorder processing in S/4HANA: BOP segments that group requirements by rules, confirmation strategies (Win, Gain, Redistribute, Fill, Lose), BOP variants, simulation and scheduled runs, monitoring results and integrating BOP with allocation and release for delivery.
Interview questions covered
- You are running backorder processing (BOP) across thousands of open sales order items after a major stock receipt. Walk through how BOP reallocates confirmed quantities and what schedule line determination factors influence which orders get priority.
- Explain how backorder processing (via rescheduling) reallocates confirmed quantities across competing sales orders when new stock becomes available.
- When a sales order item carries a delivery block, does the system still perform ATP checking and transfer requirements to MRP, and what are the implications for planning?
- In a make-to-order (MTO) scenario, how do you configure the availability check so that ATP considers only the specific sales order stock rather than general plant stock?
- What is backorder processing in SD and how does it relate to ATP and requirements transfer?
- An MTO sales order's schedule line shows zero confirmed quantity even though stock exists, and downstream delivery creation is blocked. How would you investigate whether incompletion procedure settings are contributing to this?
- As a solution architect, how would you design the availability check strategy for a global rollout where some plants use classic ATP (checking groups/rules) while a newly implemented plant is on S/4HANA's advanced ATP (aATP) with product allocation, ensuring sales document types behave consistently for order entry users?
- A customer's high-priority order for an MTO material is stuck unconfirmed because stock was consumed by earlier orders with lower priority. How would you approach backorder processing to reallocate confirmed quantities correctly?
- Walk through how the availability check determines confirmed schedule lines when checking rule, checking group, and replenishment lead time interact, and what happens if backward scheduling pushes the requested date before today.
- What is Product Allocation in SAP SD, and how does it restrict order confirmation during periods of constrained supply?
- During a make-to-order order entry, the availability check returns a confirmed date far beyond the requested delivery date, and the order still saves without any incompletion warning. What would you check to explain why incompletion did not flag this?
- A company converted to S/4HANA expecting aATP to solve scarce-product allocation, but order confirmation behaves exactly as before. What happened and what should the aATP design include?
- A new vaccine has limited supply for the first three months, and the first region to order would consume most of it. How would you use product allocation?
- After a supplier failure, rescheduling moved confirmations from key accounts to smaller customers. How would you handle it now and prevent it?
- Orders confirm based on planned orders that production later postpones, and customers get repeated date changes. How do you redesign the scope of check?
- A global manufacturer migrates from ECC with APO GATP to S/4HANA. How do you plan the availability check migration?
- Sales orders for a fast-moving product confirm dates the warehouse cannot meet, while customer service promises from stock figures. How do you explain ATP to the business and fix the process?
- Which aATP functions would you propose for a distributor with frequent shortages, a hospital channel that must always be served, and two warehouses in the same country?
- Some materials are never checked for availability and always confirm as requested, causing overpromising. How do you find out why and fix it?
- When would you choose alternative-based confirmation over simply transferring stock between plants?