Scope of Check: Checking Groups, Checking Rules, and Replenishment Lead Time

Explanation

The scope of check is the configuration object that tells the ATP logic exactly which stock and inbound/outbound elements to consider when a sales order line is checked. It is not one setting but a combination of the checking group (assigned to the material master, MRP view) and the checking rule (derived from the transaction, e.g., sales order vs. delivery). Together these two keys point to a scope of check definition that lists which quantities are included: unrestricted stock, safety stock, stock in transfer, purchase orders, planned orders, production orders, reservations, sales orders (for double-counting prevention), and deliveries. A critical intermediate-level skill is understanding how to read and adjust the scope of check table without breaking existing processes. For example, including planned orders in the scope makes ATP more optimistic (it assumes MRP-planned supply will materialize), while excluding them makes ATP conservative and may cause unnecessary backorders. Consultants must align this decision with business risk appetite: a make-to-stock consumer goods company usually wants a tighter scope excluding unconfirmed planned orders, while a make-to-order environment with reliable production may include them. Replenishment lead time (RLT) is a separate but related concept. RLT is maintained in the material master (MRP view) and represents the total time needed to procure or produce a material from scratch if no stock or supply is confirmed within the checking horizon. When ATP finds no stock and no supply elements within the checking horizon, and RLT-based check is active for the checking group, the system proposes an availability date equal to today plus RLT, effectively saying 'if you order today, procurement would take this long.' This is different from confirming against an actual planned order date; it is a fallback calculation. The checking horizon is a separate control (maintained per plant in the checking rule/checking group combination, depending on the release) that defines a future date beyond which inbound supply elements are ignored for confirmation purposes, forcing the system to rely on RLT logic beyond that point. Misconfiguring or omitting the checking horizon is a common cause of orders confirming far in the future based on speculative planned orders that were never firmed. At runtime, when a sales order item is saved, the system reads the material's checking group, combines it with the checking rule from the order type/item category configuration, looks up the scope of check, sums included supply against included demand across the requirement periods, and returns either a full confirmation, partial confirmation with a proposed delivery date, or triggers backorder logic. Understanding this chain end-to-end is essential before attempting any incident diagnosis, because most 'wrong ATP date' tickets trace back to either the wrong checking group on the material, a scope of check that excludes an expected supply element, or a checking horizon cutting off a valid planned order.

Code example

-- Illustrative scope-of-check logic (not a real SAP transaction), showing the elements typically evaluated: Scope of Check Elements (per checking group + checking rule):  Include:    - Unrestricted-use stock    - Stock in quality inspection (optional, configurable)    - Purchase orders (open quantity)    - Purchase requisitions (optional, usually excluded for firm commitments)    - Planned orders (optional - risk decision)    - Production orders (released/firmed)    - Reservations    - Sales orders (to net out already-confirmed demand)    - Deliveries (outbound, to avoid double counting) Fallback logic when no supply found within Checking Horizon:  IF material.RLT_check_active = TRUE AND no_confirmed_supply_in_horizon:      proposed_availability_date = today + material.replenishment_lead_time  ELSE:      confirmation = 0 (or next MRP-planned date if within horizon)

Real project scenario

In a discrete manufacturing rollout, the client complained that certain make-to-order items confirmed six weeks out even though production could realistically finish in two weeks because a firm production order existed. Investigation showed the checking horizon was set too short, so the system ignored the (valid, firmed) production order and fell back to RLT-based calculation using the material master's generic replenishment lead time, which had been set conservatively high for planning purposes. The fix involved extending the checking horizon for the relevant plant/checking rule combination and confirming with the client that RLT values in material masters reflected realistic worst case, not generic defaults, since RLT is a fallback used across many materials.

Common mistakes

• Assuming checking horizon and replenishment lead time are the same control; they serve different purposes and are configured separately. • Including planned orders in scope of check without discussing business risk tolerance for unconfirmed capacity with the client. • Leaving RLT at a generic default value in material master, causing unrealistic fallback dates when checking horizon is exceeded. • Changing scope of check for one checking group without regression testing other materials/plants sharing that group. • Not validating that checking horizon dates account for calendar/factory working days versus calendar days.

Best practices

• Document the business rationale for every inclusion/exclusion in the scope of check, especially planned orders and purchase requisitions. • Set checking horizon values based on realistic planning cycles, not arbitrary defaults, and review them periodically with the planning team. • Keep replenishment lead time in material master aligned with actual average procurement/production time, updated during regular data governance cycles. • Test scope of check changes against a representative sample of materials across affected plants before go-live. • Maintain a decision log mapping checking groups to business scenarios (make-to-stock vs make-to-order) for future consultants.

Interview angle

Interviewers often probe whether a candidate can explain the difference between checking horizon and replenishment lead time, and can describe what happens when ATP finds no confirmed supply. A strong answer distinguishes the scope-of-check element list from the RLT fallback mechanism and gives a concrete example of a misconfiguration symptom (e.g., far-future confirmation dates) they diagnosed.