ERPClimb logoERPClimb

SAP SD / O2C Availability Check Interview Questions

Availability Check comes up in SAP SD / O2C interviews because it is one of the few areas where an interviewer can tell, in two questions, whether you have worked with the process or only read about it.

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.

This page carries 13 reviewed SAP SD / O2C availability check interview questions, each with a complete written answer and no sign-in required. The set breaks down into 2 foundational, 5 mid-level and 6 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

The fastest way to use this page is to read the question, answer it yourself, and only then read the answer. The gap between your version and the written one is your actual revision list for availability check.

13 Availability Check questions with answers

easyAvailability Check

1. What is backorder processing in SD and how does it relate to ATP and requirements transfer?

Backorder processing (transaction CO06/V_RA or SDBOP rescheduling via V_V2) re-allocates confirmed quantities across open sales orders when stock or supply changes. It relies on the requirements transfer from sales order schedule lines to MRP, which creates the demand element checked against ATP. Rescheduling reprioritizes confirmations based on document date, priority group, or customer priority without changing requested quantities.
easyAvailability Check

2. What is Product Allocation in SAP SD, and how does it restrict order confirmation during periods of constrained supply?

Product Allocation (PAL in S/4HANA, or classic allocation via CO09/planning tables in ECC) limits the confirmable quantity of a material for a customer or channel based on predefined allocation quantities, often derived from demand planning or manual allocation tables. During ATP checks, the system checks both plant stock/receipts and the remaining allocation quantity, confirming the lower value so scarce products are distributed fairly across customers or regions rather than first-come-first-served.
mediumAvailability Check

3. Explain how backorder processing (via rescheduling) reallocates confirmed quantities across competing sales orders when new stock becomes available.

Backorder processing runs a rescheduling program (e.g., via V_RA or similar rule-based logic) that re-evaluates all open sales order schedule lines against updated stock/receipts, reallocating confirmed quantities based on priority rules like order date, customer priority, or delivery priority. It doesn't change quantities automatically online; it recalculates confirmations that must then be reviewed and released, since committed confirmations aren't overwritten without explicit rescheduling execution.
mediumAvailability Check

4. 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?

Assign a requirement class with individual requirements (special stock indicator E) tied to the strategy group/MRP type used for MTO. In OVZ9, checking rule and scope of check must include only the sales order segment (individual customer stock) instead of unrestricted plant stock. Item category and schedule line category (e.g., CP with TAK) must be configured to trigger sales-order-specific requirements, ensuring ATP checks against that specific order's stock segment only.
mediumAvailability Check

5. 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?

Check the order header/item incompleteness log first, since an incomplete item (missing required field like plant, requested delivery date, or configuration data) can prevent the availability check from running correctly or block delivery-relevant processing even if ATP found stock. If the item shows complete, then investigate schedule line category settings, availability check controller, and special stock indicator for MTO consumption, since stock may be tied to a different sales order's individual customer stock and not available for this order.
mediumAvailability Check

6. 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?

Run backorder processing (V_RA or rescheduling in newer releases) which re-executes ATP across open sales order schedule lines based on defined sort sequence (e.g., document date, priority) rather than creation sequence. Before running, confirm requirement class and item category settings allow reallocation of individual/collective stock as needed, and check if a customer-specific rescheduling profile or sort rule is required to prioritize this account. After execution, review confirmation results in COIS/VA05 before committing changes to avoid unintended de-confirmations for other customers.
mediumAvailability Check

7. 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?

I would verify whether the incompletion procedure assigned to the schedule line category actually includes a check for confirmed quantity/date versus requested date, since standard incompletion procedures often only check for missing fields, not business logic mismatches like late confirmation. I'd also check if the availability check control (OVZ9/checking group) is even active for this MTO material, since MTO items may use checking rules tied to production capacity that don't flag date delays as incompleteness, and consider whether a custom incompletion field or user-exit is needed to enforce this business rule.
hardAvailability Check

8. 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.

BOP re-executes ATP for selected order items in a defined sequence, typically driven by document date, delivery priority, or a custom sort rule maintained in rescheduling (V_RA or CO06 mass processing). It compares current confirmed schedule lines against new availability and redistributes stock, potentially reducing confirmations on lower-priority orders. Schedule line category settings (confirmed vs unconfirmed handling) and requirement type determine whether reallocation can even occur automatically or needs manual rescheduling.
hardAvailability Check

9. 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?

Yes, in standard SAP, a delivery block does not stop ATP checking or requirements transfer at order creation; these are controlled independently via the schedule line category and requirements/availability check settings, not the block itself. A delivery block only prevents delivery creation downstream. This means blocked orders can still consume plant capacity, reserve stock, and drive procurement/production even though they cannot ship, so architects must design block types carefully (credit block vs delivery block) to avoid unwanted MRP consumption for orders that may never be released.
hardAvailability Check

10. In a multi-level document flow (quotation to sales order to delivery to billing), the sales order shows confirmed schedule line quantities that match the ATP check performed at order creation, but MD04/stock-requirements list shows a different open requirement quantity for the same item. As lead architect across an ECC and S/4HANA landscape, walk through your diagnostic approach to reconcile ATP confirmation, transfer of requirements, and document flow visibility.

Start at schedule line level (VBEP) to confirm requirement type/requirement class and check if TOR is even active for that item category. Compare confirmed quantity in VBEP against open requirements in MD04 (S/4) or VBBE/VBBS (ECC) - a mismatch often means a subsequent delivery already partially consumed the requirement without the sales order being re-read, or a manual MRP change (firming) desynced planning from sales. Also check for requirement segment splits from partial deliveries and whether reduction of requirements at goods issue matches delivery quantities in VBFA. Finally verify no parallel background job (batch ATP, rescheduling) altered confirmations after order save.
hardAvailability Check

11. 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?

Keep a single global sales document type configuration where possible, but drive behavior through plant-dependent checking group assignment on the material master rather than document type variation, since availability check behavior is primarily controlled at material/checking rule level, not document type. For the aATP plant, activate the corresponding business function/scope in the ATP category and product allocation settings, while classic plants continue using OVZ2/OVZ9. Use a common schedule line category where feasible, but document clearly where confirmed quantities and rescheduling logic diverge to avoid inconsistent user experience across plants.
hardAvailability Check

12. Walk through how requirements transfer and ATP checking work for a standard sales order item using SAP standard availability check (checking group/checking rule), including which tables and background processes are involved from order entry to requirement visibility in MRP.

On saving the order, the schedule line category (e.g., CP) triggers requirements transfer if it is flagged relevant for transfer of requirements and availability check. The system checks the checking group (material master MRP3) against the checking rule (from the transaction) via table TMCVBAP-type configuration, executing scope-of-check settings including stocks, planned/production orders, and purchase orquisitions. Requirements are written to VBBE/VBEP style structures (or in S/4HANA, reflected via MD04 live data from MDVM-based tables), making the demand visible instantly in MD04 for MRP planners without a batch job.
hardAvailability Check

13. 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.

The checking group (material master) combined with checking rule (transaction-dependent) determines which stock/receipt elements (OPnn scope of check) are included. Backward scheduling first tries to confirm on the requested date using pick/pack/transport lead times; if the resulting date is before today, the system automatically switches to forward scheduling from the earliest possible date, potentially splitting into multiple confirmed schedule lines with different dates.

Related lesson

Backorder Processing, Rescheduling, and Cross-Module Integration in Availability Check

Related topics

Advanced SD Scenarios, Integration and Production SupportS/4HANA SD Transformation, Migration, Public Cloud and ArchitecturePricingEnterprise StructureBillingCustomer and Business PartnerOutput ManagementSchedule Line CategoriesItem CategoriesCopy ControlCredit ManagementSales Documents

Next practice step

Practice with Interview AITake a mock test