Availability Check
SD / O2Cintermediate

SD Availability Check Part 2: Configuring the Classic Availability Check

Key takeaway

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

Explanation

📌 KEY POINTS
✅ Checking group (OVZ2, material field MTVFP) defines how requirements are recorded (individual or summarized per day/week) and accumulation behavior.

✅ Checking rule identifies the transaction (A sales order, B delivery) and, with the checking group, selects the scope of check.

✅ Requirements class (OVZG) must allow availability check; requirements type (OVZH/OVZI) connects items to the class.

✅ Schedule line category "Availability" flag must be set as well — both levels together switch ATP on.

⚠️ Summarized requirements improve performance but make it hard to see which order holds which quantity; individual requirements do the opposite.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE

Part 1 explained ATP. Now the classic configuration objects.

━━━━━━━━━━━━━━━━━━━━
▶ 1. CHECKING GROUP (OVZ2)

  • Total sales / total deliveries: A (individual), B (daily), C (weekly) records.
  • Accumulation: whether confirmed quantities are considered when rechecking.
  • Block quantity required: quantity reserved during entry to avoid double promising.
  • No check: skip ATP for this material.

━━━━━━━━━━━━━━━━━━━━
▶ 2. CHECKING RULE

  • A: sales order, B: delivery (standard).
  • Used with checking group to find the scope of check (Part 3).

━━━━━━━━━━━━━━━━━━━━
▶ 3. REQUIREMENTS TYPE AND CLASS

  • OVZI: determination (item category + MRP type, or strategy group).
  • OVZH: requirements type → class.
  • OVZG: class settings (availability, requirements transfer, allocation).

━━━━━━━━━━━━━━━━━━━━
▶ 4. SCHEDULE LINE CATEGORY

  • VOV6 flags "Availability" and "Req./assembly".
  • Presales categories switch both off.

━━━━━━━━━━━━━━━━━━━━
▶ 5. PLANT VS STORAGE LOCATION

  • Standard: check at plant level.
  • If storage location is entered in the order item, check includes that storage location's stock (scope settings apply).
  • Storage location-specific MRP areas affect planning, not SD directly.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

  1. Assign checking group 02 to the material (MM02, Sales: General/Plant or MRP 3).
  2. Review OVZ2 settings for 02.
  3. Check requirements type/class of the item.
  4. Check the schedule line category flags.
  5. Create an order and verify ATP ran (Procurement tab / availability screen).

✅ CHECKPOINT: you can switch ATP off for one material by configuration and on again, and explain every object involved.

Code example

ABAP Code
===== STEP 1: checking group (SPRO > Sales and Distribution > Basic Functions >             Availability Check and TOR > Availability Check > Define Checking Groups)  (OVZ2)Group | Total sales | Total deliv. | Accumulation | Block qty req. | No check01    | B (daily)   | B            | 1            | –              | –02    | A (indiv.)  | A            | 1            | X              | –KP    | –           | –            | –            | –              | X  (no check) ===== STEP 2: material master =====MM02 > MRP 3 (or Sales: General/Plant) > Availability check MTVFP = 02 ===== STEP 3: requirements =====OVZI item category TAN + MRP type PD → requirements type 011 / KSLOVZH requirements type → classOVZG class: Availability X | Req. transfer X | Allocation ind. per scenario ===== STEP 4: schedule line category (VOV6) CP: Availability X, Req./assembly X

Real project scenario

A client set checking group 01 (daily summarized) for all materials to reduce table load. When customer service had to explain which orders held stock for a scarce product, nobody could see it quickly, and backorder decisions were made blind. For the 400 scarce and high-value materials the team switched to individual requirements (02), kept summarized for the long tail, and documented the rule in the material master governance.

Common mistakes

  • Setting ATP flags only on one level (schedule line or requirements class).
  • Using "no check" checking groups for materials that are actually scarce.
  • Summarized requirements for materials needing order-level allocation decisions.
  • Forgetting block quantity for high-volume parallel order entry.
  • Confusing checking group with MRP settings.

Best practices

  • Choose checking groups by material behavior (scarce vs abundant).
  • Keep requirements class and schedule line flags aligned.
  • Document checking group rules in material governance.
  • Test ATP on and off per material.
  • Use individual requirements where allocation transparency matters.

Interview angle

Questions: "What is a checking group?", "What controls whether ATP runs?", "Difference between individual and summarized requirements?"
Strong answer: checking group in material (OVZ2) with requirements recording and accumulation; checking rule A/B; requirements type/class (OVZI/OVZH/OVZG) plus schedule line category flag switch ATP; individual requirements give order-level transparency, summarized improve performance.

Practice this lesson

Quick check

1. In the material master, what is the primary function of the checking group used for availability check?

2. When does the availability check consider a specific storage location's stock in the sales order?

3. What does setting the requirements as 'individual requirements' on the material master control with respect to transfer of requirements?

Interview questions

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

Answer it in your own words first, then compare.

2. Some materials are never checked for availability and always confirm as requested, causing overpromising. How do you find out why and fix it?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics