Search Results msc_atp_rules_pk

Overview

MSC_ATP_RULES is a table in the MSC schema (Advanced Supply Chain Planning) that stores rules and options used by Oracle EBS when computing Available To Promise (ATP). Each row represents a named ATP rule — a reusable configuration object consumed by the planning and order-promising engines to determine supply, demand, and time-fence behavior for ATP calculations. The table holds 65 documented columns in ETRM 12.2.2 and is generally understood to exist in both 12.1.1 and 12.2.2 with comparable structure. ATP rules are referenced when Oracle Order Management, Global Order Promising, and Advanced Supply Chain Planning perform availability checks and promise dates.

From a data-modeling standpoint, the documented relationship data classifies MSC_ATP_RULES as standalone (heuristic Data Vault classification). This suggests it behaves as a small reference/lookup table rather than a transactional entity within the FK graph; downstream consumers reference RULE_ID without a declared foreign key dependency from within the MSC schema footprint.

Key Information Stored

The table's unique business-key candidate is MSC_ATP_RULES_U1 (SR_INSTANCE_ID, RULE_ID), which is also the Primary Key MSC_ATP_RULES_PK. SR_INSTANCE_ID identifies the source instance; RULE_ID is the surrogate identifier of the rule itself. The most significant columns include:

• RULE_ID / SR_INSTANCE_ID — the composite primary key and natural join keys.
• RULE_NAME / DESCRIPTION — user-facing rule identity and documentation.
• ACCUMULATE_AVAILABLE_FLAG, ACCUMULATION_WINDOW — control whether ATP accumulates available supply across a time window.
• FORWARD_CONSUMPTION_FLAG / BACKWARD_CONSUMPTION_FLAG / PAST_DUE_DEMAND_CUTOFF_FENCE / PAST_DUE_SUPPLY_CUTOFF_FENCE — govern how demand and supply are consumed relative to the current date.
• INFINITE_SUPPLY_FENCE_CODE / INFINITE_SUPPLY_TIME_FENCE / AGGREGATE_TIME_FENCE_CODE / AGGREGATE_TIME_FENCE — define tolerance fences and aggregation horizons.
• ACCEPTABLE_EARLY_FENCE / ACCEPTABLE_LATE_FENCE — define acceptable promise-date tolerances.
• DEFAULT_ATP_SOURCES / MPS_DESIGNATOR / USER_ATP_SUPPLY_TABLE_NAME / USER_ATP_DEMAND_TABLE_NAME — specify which sources supply ATP data, including user-defined tables.
• INCLUDE_* flags (INCLUDE_SALES_ORDERS, INCLUDE_PURCHASE_ORDERS, INCLUDE_ONHAND_AVAILABLE, INCLUDE_DISCRETE_WIP_DEMAND/RECEIPTS, INCLUDE_INTERORG_TRANSFERS, INCLUDE_INTERNAL_ORDERS, etc.) — determine which demand and supply classes contribute to ATP.
• Standard WHO audit columns (LAST_UPDATE_DATE, CREATED_BY, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, PROGRAM_ID, REQUEST_ID) and ATTRIBUTE1–15 — trace change history and support extensibility.

Common Use Cases and Queries

Typical scenarios include reviewing which supply/demand sources a rule includes, auditing fencing configuration, and copying rules across instances. A representative query lists active rules and their key inclusion flags:

• SELECT RULE_ID, RULE_NAME, ACCUMULATE_AVAILABLE_FLAG, FORWARD_CONSUMPTION_FLAG, INFINITE_SUPPLY_FENCE_CODE FROM MSC.MSC_ATP_RULES WHERE SR_INSTANCE_ID = :inst;
• SELECT RULE_NAME, INCLUDE_SALES_ORDERS, INCLUDE_PURCHASE_ORDERS, INCLUDE_ONHAND_AVAILABLE, DEFAULT_ATP_SOURCES FROM MSC.MSC_ATP_RULES ORDER BY RULE_NAME;

Common reporting use cases include comparing rule configurations between development and production, verifying that on-hand and purchase-order supply are enabled, and auditing fence values for order-promising policy compliance.

Related Objects

Because the table is classified as standalone in the documented relationship data, its dependents are implicit rather than declared through FK constraints. The most significant related objects in practice include:

• Order Management / Global Order Promising — consume RULE_ID via the ATP rule profile option and assignment.
• MSC_ATP_RULES reference data surfaced through the ATP Rules setup UI and concurrent programs (programatically identified by PROGRAM_ID).
• MSC_ATP_SUPPLY / demand-related planning tables — referenced by DEFAULT_ATP_SOURCES and USER_ATP_*_TABLE_NAME.
• MPS_DESIGNATOR — links the rule to a master production schedule when the rule scopes MPS-based ATP.

Implementation activities should confirm rule ownership before removal, because historically assigned rules can break promise-date computation if deleted.