Advanced ATP in SAP S/4HANA

The core availability check — the aATP successor to the classic ATP check. It calculates what can be promised from stock plus supply elements, minus existing confirmed demand, using the checking rule and scope of check.

Why it matters: This is the baseline. Every order line still gets checked here; the other capabilities build on top of it.

Reserves and rations constrained supply across customers, regions, or channels before it is consumed first-come-first-served. Allocation is planned in characteristic-based buckets and consumed as orders confirm.

Why it matters: Essential when demand exceeds supply and you must protect key customers or markets. Replaces the older, more rigid product allocation of ECC.

Fiori: Manage Product Allocation Planning Data

Re-evaluates and reprioritises already-confirmed and unconfirmed order lines when the supply situation changes — mass, rules-based, and scheduled rather than manual.

Why it matters: The biggest single upgrade over classic V_V2 rescheduling. Confirmations can be won, kept, redistributed, or filled based on business priority rather than order-entry sequence.

Fiori: Configure BOP Segment · Configure BOP Variant · Monitor BOP Run

When the requested plant cannot confirm, aATP automatically checks alternatives — another plant, another distribution channel, or a substitute — and confirms from there.

Why it matters: Turns a "cannot confirm" into a confirmed line without manual intervention. Requires a substitution strategy to be configured.

A Fiori-based cockpit that lets a business user review competing requirements for a constrained product and decide, line by line, who actually gets the stock before delivery creation.

Why it matters: Puts the final allocation decision in the hands of a planner or customer-service lead, with full visibility, instead of whoever runs the delivery job first.

Fiori: Release for Delivery

Confirming against planned orders

The scope of check includes planned orders, so the system promises supply that planning may never convert. Tighten the checking rule to firm receipts where the business needs reliable dates.

Transfer of Requirements switched off

Demand never reaches MRP, so replenishment is never triggered — but ATP still confirms against whatever supply it can see. Confirmations then cannot be delivered.

BOP designed without a written priority policy

Segments end up encoding whoever shouted loudest. Agree the policy in business terms first, then build segments to match it.

Allocation set up but never maintained

Allocation buckets that are not refreshed become a constraint on the business rather than a control. Plan who owns the ongoing maintenance.

Assuming aATP fixes bad master data

Lead times, lot sizes, and planning parameters still drive the answer. Advanced logic on poor master data produces confident, wrong dates.

What is Advanced ATP (aATP) in SAP S/4HANA?

Advanced ATP is the availability-check framework embedded in SAP S/4HANA. It extends the classic ATP check with five capabilities: Product Availability Check, Product Allocation, Backorder Processing (BOP), Alternative-Based Confirmation, and Release for Delivery. The key architectural point is that it is embedded — it runs inside S/4HANA on HANA rather than in a separate APO/GATP system, so checks are real time and there is no interface to keep in sync.

What is the difference between classic ATP and advanced ATP?

Classic ATP answers one question: can this order line be confirmed from stock and expected supply? Advanced ATP adds decision-making on top of that. It can ration constrained supply through product allocation, re-prioritise thousands of order lines through rules-based Backorder Processing, automatically look for alternative plants or materials, and hand the final call to a business user through the Release for Delivery app. Classic ATP confirms in the sequence orders arrive; aATP confirms according to business priority.

What is Backorder Processing (BOP) in S/4HANA?

BOP is the aATP capability that re-evaluates existing confirmations when the supply situation changes. You define a BOP segment (which requirements the run covers, selected by filters like customer, priority, or delivery date) and assign each segment a confirmation strategy — Win, Gain, Redistribute, Fill, or Lose. A BOP run then reconfirms all selected requirements according to those rules. It replaces the classic V_V2 rescheduling, which effectively worked in order-date sequence with far less control.

What are the BOP confirmation strategies?

There are five. Win — the requirement may gain confirmation, including taking it from lower-priority lines. Gain — may improve confirmation only from spare supply. Redistribute — its confirmation may be taken away and given to higher-priority demand. Fill — keeps what it has and may be topped up. Lose — confirmation may be removed entirely so higher-priority demand can be served. Assigning the right strategy to the right customer segment is the core design decision in a BOP project.

What is Alternative-Based Confirmation (ABC)?

Alternative-Based Confirmation lets aATP look beyond the originally requested source when it cannot confirm. If the requested plant has no stock, the system checks configured alternatives — a different plant, a different distribution channel, or a substitute material — and confirms from the first viable option according to the substitution strategy. It converts what would have been an unconfirmed line into a confirmed one without a user manually hunting for stock.

What is the Release for Delivery app used for?

Release for Delivery is a Fiori app that gives a business user control over who receives constrained stock. Instead of delivery creation being effectively first-come-first-served, a planner or customer-service lead reviews the competing requirements for a material, sees the impact of each choice, and releases specific quantities to specific orders before deliveries are created. It is typically used for high-value or allocation-constrained products.

Is the checking rule still relevant in advanced ATP?

Yes. The checking rule and scope of check (OVZ9) still define what the availability check counts — which stock types are included, which receipts (purchase orders, production orders, planned orders) are considered, whether existing requirements are netted off, and whether replenishment lead time is used. aATP builds its advanced capabilities on top of this foundation, so a misconfigured scope of check still produces wrong confirmations, exactly as in ECC.

Does aATP replace Transfer of Requirements?

No. Transfer of Requirements (TOR) is still how sales demand reaches MRP, and it is still controlled by the schedule line category. TOR and ATP remain complementary: TOR pushes demand into planning, and the availability check reads the resulting supply picture back to commit dates to customers. If TOR is switched off, aATP can still confirm against supply that was never triggered by that demand — a classic cause of confirmations that cannot actually be delivered.