6.1 Availability Check Fundamentals: Checking Groups, Checking Rules, and Scope of Check

Availability Check Fundamentals: Checking Groups, Checking Rules, and Scope of Check

In modern supply chain management and Order-to-Cash (O2C) processing, promising an accurate delivery date to a customer is a critical commercial commitment. An enterprise cannot afford to overpromise inventory, risking stockouts and delayed shipments, nor can it hold excessive safety stock that drives up working capital. The Available-to-Promise (ATP) check in SAP S/4HANA reconciles these competing objectives by calculating real-time, time-phased product availability during sales document entry and logistics execution.

Unlike a static stock lookup (such as viewing unrestricted stock in transaction MMBE), the ATP check is dynamic. It evaluates not only the current physical stock in the warehouse, but also future anticipated receipts (purchase orders, production orders, planned orders) and future confirmed commitments (sales orders, deliveries, reservations) across a timeline. This guarantees that stock allocated to an existing customer cannot be mistakenly re-promised to another.

---

The ATP Configuration Triad: Checking Group, Checking Rule, and Scope of Check

The ATP calculation engine is controlled by an interlocking three-part configuration model known as the ATP Configuration Triad:

[ Material Master: MARC-MTVFP ]              [ Calling Application / Transaction ]
       Checking Group                                  Checking Rule
       (e.g., 01 or 02)                               (e.g., A or B)
              │                                              │
              └──────────────────────┬───────────────────────┘
                                     ▼
                         [ Customizing Table T441V / OVZ9 ]
                                Scope of Check
              (Controls Stocks, Planned Receipts, and Committed Issues)

1. The Checking Group (Material Master)

The Checking Group is maintained on the material master record within the Sales: General/Plant Data view and the MRP 3 view (field MARC-MTVFP). It defines:

• Requirement Accumulation: Whether customer requirements are passed to Material Requirements Planning (MRP) as individual records or consolidated daily/weekly buckets.
  • 01 — Daily Requirements: Demands from multiple sales orders on the same calendar day are consolidated into a single daily total. This reduces the number of planning records but obscures individual document traceability.
  • 02 — Individual Requirements: Each sales order line item generates an independent requirement record. This provides discrete document pegging, allowing planners to identify exactly which sales order consumed which receipt.
  • KP — No Check: Availability check is deactivated entirely (common for non-stock consumables or bulk commodity packaging).
• Lock Behavior: Whether the material's inventory record is locked with quantity reservation during sales order creation to prevent concurrent over-allocation.

2. The Checking Rule (Calling Application)

The Checking Rule is hardcoded or assigned to the specific business transaction calling the ATP engine. It identifies the operational stage of the document:

• A — Sales Order Processing (SD sales order creation and modification via VA01/VA02).
• B — Outbound Delivery Processing (Shipping execution via VL01N/VL02N).
• PP — Production Order Component Check (Shop floor availability check via CO01/CO02).

Why Checking Rules Differ Between Sales Orders and Deliveries

The separation of Checking Rules between sales orders (A) and outbound deliveries (B) is an essential architectural design in SAP:

• During Sales Order Entry (Rule A): The customer order may be placed weeks or months before the delivery date. The business can reasonably include planned receipts, planned orders, purchase requisitions, and can check against the Replenishment Lead Time (RLT) because the manufacturing plant has sufficient time to produce or acquire new inventory.
• During Outbound Delivery Creation (Rule B): The warehouse is preparing to physically pick, pack, and stage the goods within hours or days. At this execution stage, long-term purchase requisitions and planned production orders are useless—only physically available unrestricted stock, quality inspection stock nearing release, or immediate inbound shipments can be permitted. Replenishment Lead Time is deactivated.

---

The Scope of Check: Transaction OVZ9

The combination of the Checking Group (from the material) and the Checking Rule (from the transaction) forms the access key for the Scope of Check in transaction OVZ9 (table T441V). The Scope of Check dictates exactly which stock categories, receipt elements, and demand elements are included in the ATP calculation. The values in the table below are an example configuration; each company sets its own scope. The official course example, for instance, includes purchase orders but excludes stock in quality inspection.

---

Cumulative ATP Quantities Calculation Logic

The fundamental calculation of ATP at any given point in time $t$ is expressed by the baseline formula:

$$\text{ATP Quantity}(t) = \text{Usable Physical Stock} + \sum \text{Planned Receipts}(t) - \sum \text{Confirmed Commitments}(t)$$

However, a simple period-by-period check can lead to severe shortages if future commitments are ignored. SAP uses Cumulative ATP Logic (with calculation of missing parts) to ensure that confirming a new order in an earlier timeline bucket does not create an unfulfillable deficit for an already-confirmed order in a later timeline bucket.

Worked Example: The Danger of Non-Cumulative Checking

Consider a manufacturing plant with the following inventory situation for high-performance industrial pumps:

• Current On-Hand Stock (Day 1): 50 units
• Confirmed Order 1 (Due Day 3): 30 units (Confirmed)
• Inbound Purchase Order Receipt (Due Day 10): 40 units
• Confirmed Order 2 (Due Day 12): 50 units (Confirmed)

Now, a new customer calls on Day 1 requesting 30 units for delivery on Day 5:

• Naive (Non-Cumulative) Period Calculation at Day 5:
  • Stock on Day 1 = 50 units.
  • Order 1 consumed 30 units on Day 3 $\rightarrow$ Remaining physical stock = 20 units.
  • Naive evaluation might see 20 units available, or if checking against Day 10 receipts, falsely assume plenty of stock exists.
• Cumulative ATP Analysis Across the Timeline:

The running balance is not the cumulative ATP quantity. For ATP, each confirmed requirement reduces the ATP quantity of the stock or receipt closest to it when looking into the past (official S46001 content): Order 2 (Day 12) uses the 40 units of the Day 10 receipt and 10 units of stock, and Order 1 (Day 3) uses 30 units of stock. That leaves an ATP quantity of 10 units on the stock and none on the receipt, so the cumulative ATP quantity is 10 units from Day 1 onward, and still 10 units after Day 10.

Look at what each element really covers. Order 2 needs 50 units on Day 12, but the purchase order brings only 40, so 10 units of the Day 1 stock must stay reserved for Order 2. Of the 50 units in stock, 30 are committed to Order 1 and 10 to Order 2, which leaves 10 units free. The receipt on Day 10 cannot help a requirement on Day 5, because a requirement can only use stock and receipts dated on or before its own requirement date.

Under Cumulative ATP Logic, the system therefore confirms only 10 units for Day 5. Because the cumulative ATP quantity is 10 units on every later date as well, the remaining 20 units stay unconfirmed until new receipts are planned (or, when checking with replenishment lead time, a date after the lead time is reached). Confirming 30 units would have taken stock that Order 2 depends on.

---

Replenishment Lead Time (RLT) in ATP Processing

The Replenishment Lead Time (RLT) is the total duration required to manufacture or externally procure a material if no stock or planned receipts are available. In customizing (OVZ9), the flag Check Without Replenishment Lead Time dictates how the ATP engine behaves when demand extends beyond this horizon.

Check WITH RLT (Flag Unchecked)

• Standard for Sales Orders (Checking Rule A).
• If the customer's Requested Delivery Date falls after the expiration of the Replenishment Lead Time, the system assumes infinite availability.
• The system confirms 100% of the requested quantity on the requested delivery date, even if on-hand inventory is zero and no purchase orders exist!
• Business Rationale: The enterprise has adequate time to purchase raw materials or execute production before the goods are scheduled to leave the plant.

Check WITHOUT RLT (Flag Checked)

• Standard for Deliveries (Checking Rule B) and Constrained/MTO Scenarios.
• The system confirms orders only if physical stock or actual scheduled receipts (firm POs, production orders) exist.
• If stock is zero and no receipts exist, the confirmed quantity remains 0, regardless of how far into the future the requested delivery date lies.
• Business Rationale: Essential for scarce, allocation-controlled materials or high-value engineered goods where production cannot begin without manual planning intervention.

Timeline: Today (Day 0) ─────────────────── RLT Boundary (Day 20) ──────────────────> Future
                          [ Inside RLT ]                               [ Beyond RLT ]
With RLT:      Check against physical stock & firm receipts.        INFINITE AVAILABILITY!
               Shortages cause delayed confirmation.                Orders confirmed in full.

Without RLT:   Check against physical stock & firm receipts.        STILL LIMITED TO REAL STOCK!
               No stock = 0 confirmed.                              No stock = 0 confirmed.

How SAP Calculates Replenishment Lead Time

The calculation of RLT depends on the material's procurement type in the Material Master:

1. Manufactured Materials (Internal Production — Procurement Type E)

• If the Total Replenishment Lead Time (MARC-WZEIT) is maintained in the MRP 3 view, the system takes this fixed number of calendar/work days directly.
• If MARC-WZEIT is blank, the system dynamically calculates the lead time using parameters from the Work Scheduling / MRP 2 views:

$$\text{RLT} = \text{In-House Production Time (MARC-DZEIT)} + \text{Goods Receipt Processing Time (MARC-WEBAZ)}$$

2. Externally Procured Materials (Trading Goods — Procurement Type F)

For trading goods purchased from external suppliers, RLT is calculated dynamically by summing three parameters:

$$\text{RLT} = \text{Purchasing Processing Time} + \text{Planned Delivery Time (MARC-PLIFZ)} + \text{GR Processing Time (MARC-WEBAZ)}$$

• Purchasing Department Processing Time: Working days required by purchasing to create and send the purchase order (maintained per plant in the plant parameters for materials planning).
• Planned Delivery Time: Calendar days required by the vendor to supply the goods after PO receipt (MARC-PLIFZ or Purchasing Info Record).
• Goods Receipt (GR) Processing Time: Work days required by the receiving warehouse to unpack, inspect, and place goods into unrestricted inventory (MARC-WEBAZ).

---

What the Official ATP Course Adds

Requirement Date and Check Level

The availability check does not use the requested delivery date directly. Scheduling first calculates the material availability date (the date the goods must be ready for shipping), and that date is the requirement date of the item. The check then runs in the delivering plant of the item. If a storage location is in the item, the check also runs at storage location level, and the level with the lower cumulative ATP quantity decides the result. Sales orders normally have no storage location (classic ATP cannot determine one automatically), while deliveries usually do. With aATP activated, Alternative-Based Confirmation can determine and substitute plants and storage locations automatically.

Shortage Check

Because the basic check only compares a new requirement with cumulative ATP quantities, moving receipts into the future can leave already confirmed orders short. A shortage check can be activated in the checking group. With value 3, for example, unconfirmed requirements also reduce the cumulative ATP quantity when a new order is created, while only confirmed quantities count in change mode.

Which App Shows Availability?

Statements about availability can only be based on the cumulative ATP quantity. The Availability Overview app shows it. The Monitor Stock/Requirements List, Stock - Single Material, and Check Material Coverage apps show stocks and requirements but not the cumulative ATP quantity, so they should not be used to decide whether a new requirement can be confirmed.

Delivery Agreements

When items are not available as requested, the delivery agreements decide what happens:

• Complete delivery (header): the whole order waits until all items can be delivered. It is proposed from the sold-to party's business partner master.
• Partial delivery (item): available items or quantities can go ahead. It is proposed from the sold-to party or, with higher priority, from the customer-material info record.

Both can be changed manually in the order.

ATP and Transfer of Requirements Work Together

If customer requirements are relevant for MRP, the next MRP run creates purchase requisitions or planned orders for a shortage. Those receipts help the order only if they are in the scope of check, and even then the saved order is not rechecked automatically: backorder processing is needed to improve its confirmation. With aATP and PP/DS, Supply Creation-Based Confirmation creates the receipt elements directly from the availability check and confirms against them immediately, without an MRP run.

High-Frequency Exam Traps and Best Practices

• Trap: Conflating Checking Group with Checking Rule: Remember that the Checking Group is an attribute of the Material (MARC), while the Checking Rule is an attribute of the Transaction (A for sales order, B for delivery). Neither can determine the scope of check alone.
• Trap: Assuming RLT applies to Deliveries: Outbound deliveries should never check with Replenishment Lead Time. A delivery represents imminent physical execution; confirming an outbound delivery based on future procurement lead time causes shipping blockages and picking failures.