6.3 Advanced ATP (aATP), Backorder Processing (BOP), and Transfer of Requirements

Advanced ATP (aATP), Backorder Processing (BOP), and Transfer of Requirements

In SAP ERP, rescheduling sales orders relied on classic backorder transactions such as V_V2, which rechecked documents largely in their entry sequence, and a different plant had to be entered manually. In SAP S/4HANA, Advanced Available-to-Promise (aATP) is the business function that adds product allocation, alternative-based confirmation, configurable backorder processing, and further functions to the availability check. In SAP S/4HANA Cloud Private Edition and on premise it must be activated and requires an additional license; in SAP S/4HANA Cloud Public Edition, aATP is the only code line.

The official course is based on a system with aATP activated, so its terminology (BOP segments, variants, and confirmation strategies) appears in the course examples.

---

Classical ERP ATP vs. S/4HANA Advanced ATP (aATP)

---

The Core Capabilities of SAP S/4HANA aATP

Advanced ATP is not a single feature. Besides backorder processing, its capabilities include product allocation, alternative-based confirmation, release for delivery, and supply creation-based confirmation (with PP/DS). Two of them in detail:

1. Product Allocation (PAL)

When market demand outstrips available production capacity (such as during new product launches, raw material shortages, or seasonal demand surges), an enterprise must avoid allowing a single high-volume customer to order the entirety of warehouse inventory, starving other key accounts. Product Allocation (PAL) enforces planned distribution quotas:

• Allocation Dimensions: Quotas can be maintained along multi-tiered dimensions, including Sales Organization, Distribution Channel, Customer Group, Individual Strategic Customer, or Geographic Region.
• Time Buckets: Allocations are defined in discrete time intervals (weekly, monthly, quarterly).
• ATP Gating: During sales order entry, the ATP check evaluates both physical stock and the customer's remaining allocation balance. Even if 10,000 units sit in the warehouse, if the buyer's weekly quota is 500 units and they have already consumed 400, the sales order will only confirm 100 units.

2. Alternative-Based Confirmation (ABC)

In traditional order processing, if the requested delivering plant has zero stock, the order line item remains unconfirmed unless a customer service representative manually changes the plant or splits the line. Alternative-Based Confirmation (ABC) automates this decision in real time:

• Plant Substitution: If Plant 1010 has insufficient inventory, ABC evaluates alternate distribution centers (e.g., Plant 1020 or Plant 1030) based on predefined substitution rules.
• Storage Location Substitution: Diverts orders between automated high-rack storage and manual pick locations.
• Maintenance: Substitution strategies for locations are maintained in the Manage Substitutions - Locations app.

---

Backorder Processing (BOP) and the Confirmation Strategies

Backorder processing exists for three reasons named in the official course. First, a saved order is never rechecked by itself, even when new receipts arrive. Second, the availability check works on a first come, first served basis, so an important order entered later may find no stock. Third, an order confirmed against a planned receipt keeps an unrealistic date if that receipt moves. Backorder processing revises existing confirmations to solve these problems.

In aATP, a run is built from three objects:

• BOP segment: a saved selection that decides which requirements are selected and in which priority sequence they are processed.
• Confirmation strategy: assigned to each segment in the Configure BOP Variant app; it decides how the requirements of that segment are treated.
• BOP variant: defines which segments are included in a run and with which strategies. Variants are scheduled as background jobs, and results are checked in the Monitor BOP Run app.

The official course lists these confirmation strategies:

A typical design assigns Lose to a low-priority segment: its confirmations are released, the cumulative ATP quantity increases, and a segment with Improve or Win can then use that quantity.

---

Transfer of Requirements (TOR) and S/4HANA Simplification

Transfer of Requirements (TOR) is the integration bridge between Sales and Distribution (SD) and Material Requirements Planning (PP-MRP / MM). When a customer places a sales order, the demand must be transmitted to the manufacturing and purchasing departments so replenishment orders can be triggered.

The Requirement Type and Requirement Class Architecture

The configuration chain governing TOR runs through two fundamental entities:

  Item Category (e.g., TAN) + MRP Type (e.g., PD)
                │
                ▼
        Requirement Type (e.g., 011 - Delivery Requirement)
                │
                ▼  (requirement class assigned to the type)
        Requirement Class (e.g., 041 - Order/Delivery Requirement)
                ├── Availability check active?
                ├── Requirements transfer active?
                └── Further settings (e.g., allocation, costing)

1. Requirement Type Determination (in this order):
   • From the strategy group in the material's MRP 3 view (through the main planning strategy); if none is found, from the MRP group.
   • Otherwise from the item category and the material's MRP type (transaction OVZI), and finally from the item category alone.
2. Requirement Class Configuration (requirement types in OVZH, requirement classes in OVZG):
   • The Requirement Type points directly to a Requirement Class (table T459K).
   • The Requirement Class contains the primary operational switches:
     • Availability check: Activates or deactivates the ATP check for sales documents.
     • Requirements transfer: Activates or deactivates passing sales requirements to MRP.
   • Both checks can additionally be switched off at schedule line category level.

S/4HANA Simplification: No Totals Table VBBS

In classic SAP ERP, individual requirements were stored in VBBE, while summarized requirements (checking groups with daily or weekly totals) were stored in the totals table VBBS. Writing totals records created lock contention during parallel order entry. In SAP S/4HANA, VBBS is no longer used: requirements are stored as individual records in VBBE, and totals are calculated when they are needed.