Configuring Availability Check: Checking Groups, Scope of Check, and Document Flow
Learn how checking groups, checking rules, and scope of check are configured together, and how ATP results flow from sales order to delivery in real transactions.
Explanation
Once the business purpose of ATP is clear, the next step for an SD consultant is understanding how the configuration pieces fit together and how they behave at runtime across the document flow. The checking group is maintained on the material master (Sales: General/Plant view, availability check field) and determines the fundamental behavior: whether the material is checked at all, whether it uses simple quantity-based checking against stock only, or checks against the full planning situation (production orders, purchase orders, reservations, dependent requirements, and so on). A common standard checking group enables checking against planning with individual requirements, meaning each sales order creates its own requirement record visible in planning (MRP-relevant), which is typically preferred for make-to-order or tightly controlled environments, versus collective requirements which aggregate demand for performance reasons in high-volume make-to-stock scenarios. The checking rule is assigned per transaction type in configuration (for example, a different rule can apply to standard sales orders versus deliveries or versus other order types), allowing the same material to be checked slightly differently depending on which business process is running. The combination of checking group and checking rule points to an entry in the scope of check configuration table, which explicitly lists which stock categories (safety stock, stock in transfer, quality inspection stock) and which inward/outward movements (purchase orders, purchase requisitions, planned orders, production orders, reservations, sales orders, deliveries) are included or excluded from the ATP calculation. This table is where the real business logic lives: for instance, a company might choose to include firmed production orders but exclude unfirmed planned orders, reflecting a conservative promise policy that does not rely on unconfirmed future supply. At runtime, when a sales order line item is entered, the system triggers the availability check based on requested delivery date and quantity, using the checking rule tied to the sales document type and the checking group from the material master, filtered through the scope of check. The result populates schedule lines with confirmed quantities and dates, which may differ from the requested ones. If a shortage exists, the system may present the ATP dialog box showing options such as one-time delivery on a later date, delivery proposal (partial now, rest later), or complete delivery only. These options are configuration-driven (rule for availability check outcomes) and can be restricted per sales area or order type to match business policy, for example disallowing partial deliveries for certain customer segments. The availability check does not stop at order creation. It is re-triggered at key points: during delivery creation (where a delivery-specific checking rule often applies, sometimes more conservative than the order-time check, since it reflects the near-real-time picking situation), during backorder processing, and whenever relevant supply or demand changes trigger a rescheduling run. This means confirmed quantities on an order are not necessarily final until the delivery is actually created and, in stricter setups, until picking is confirmed. Integration with MM and PP is central here: purchase order receipts, goods movements, and production order confirmations all update the ATP situation in near real time in most configurations, so timing of goods receipt postings has a direct, visible effect on what sales can promise. In S/4HANA, the underlying ATP check leverages the simplified data model (no separate aggregate tables like older summary tables), generally improving performance, but the classic checking group/rule/scope-of-check configuration model remains conceptually the same as ECC for standard ATP. Advanced ATP (aATP) in S/4HANA on-premise adds capabilities like product allocation checks and more sophisticated backorder processing, configured as an addition to, not a replacement of, this classic setup; public cloud editions may present a curated subset of these configuration options through Fiori-based configuration apps rather than full IMG access.
Real project scenario
During a rollout, a retail distribution client wanted delivery proposals disabled for their top-tier wholesale customers because partial shipments increased freight costs disproportionately. The consulting team achieved this by adjusting the availability check rule behavior at the sales document type level for the relevant order types used by those customers, rather than changing the global scope of check, preserving normal partial-delivery behavior for other customer segments.
Common mistakes
• Changing scope of check globally to solve a problem that only affects one sales document type or customer segment. • Overlooking that delivery-time availability check can use a different, often stricter, checking rule than order-time check, causing apparent 'disappearing' confirmed quantities. • Setting checking groups to individual requirements everywhere without evaluating system performance impact on high-volume materials. • Forgetting that goods receipt or production confirmation timing directly affects promised dates, then troubleshooting ATP as a 'bug' when it is a timing/process issue. • Not testing rescheduling and backorder processing behavior after changing scope of check, since existing open orders can be affected unexpectedly.
Best practices
• Map out scope of check settings in a simple matrix (checking group x checking rule) during design workshops so business stakeholders can validate the logic visually. • Keep delivery-time checking rules aligned with realistic warehouse timing rather than mirroring order-time rules by default. • Use individual requirements selectively for materials where order-level visibility in planning is genuinely needed, and collective requirements elsewhere for performance. • Coordinate scope-of-check changes with MM/PP teams since the same configuration affects what planning treats as demand. • Test end-to-end from order creation through delivery and backorder processing whenever checking rule or scope of check configuration changes, not just at order entry.
Interview angle
A frequent scenario-based question asks candidates to diagnose why a sales order confirms full quantity but the subsequent delivery only confirms partial quantity; the expected answer centers on different checking rules being used at order versus delivery time and possible timing changes in stock/receipts between the two events.