Search Results rla_demand_headers_all

Overview

RLA_DEMAND_HEADERS_ALL is a table within the Oracle E-Business Suite Release Management Integration Kit (RLA) module. Its documented description is "Release Management Demand Headers," indicating that it stores header-level demand records consumed by the RLA integration layer. The RLA module itself is classified in the ETRM metadata as Obsolete, and the implementation note explicitly states "Not implemented in this database." This distinction is significant: the table definition is retained in the ETRM repository for historical, upgrade, and dependency-tracking purposes, but it may not exist as a physical object in every environment, particularly in later 12.1.1 or 12.2.2 installations where the RLA integration kit has been retired or superseded.

From a data modeling perspective, the metadata classifies this object as standalone using a heuristic Data Vault assessment mined from its foreign key structure. In Data Vault terms, this suggests RLA_DEMAND_HEADERS_ALL behaves as a hub-like entity — it holds the primary key and descriptive attributes for a business concept (a demand header) without documented inbound or outbound hub-to-hub relationships of its own. The table participates as a referenced parent rather than as a link between two other hubs.

Key Information Stored

The explicitly documented columns in the ETRM metadata are limited, but the following are confirmed:

• DEMAND_HEADER_ID — The surrogate primary key, defined by the constraint RLA_DEMAND_HEADERS_PK. This is the unique identifier for each demand header record and is the column referenced by all dependent tables.

The primary key constraint RLA_DEMAND_HEADERS_PK is the only index documented in the metadata. No secondary unique indexes or business-key candidates are published. In comparable RLA and demand-planning structures, business-key candidates typically include a source document number, demand type, and organization identifier, but these are not enumerated in the available ETRM content and should be verified against the live data dictionary where the table is implemented. Because the table is marked obsolete and not implemented in the documented database, a column-level inventory from ALL_TAB_COLUMNS should be treated as authoritative for any given environment.

Common Use Cases and Queries

The principal use case for this table is dependency resolution and impact analysis. Two documented foreign keys reference DEMAND_HEADER_ID, which means the table acts as a lookup parent for downstream demand records. A typical diagnostic query joins the parent to its dependents to trace origin:

• Listing demands that feed WMS replenishment: SELECT d.demand_header_id, w.demand_header_id FROM rla_demand_headers_all d, wms_repl_demand_gtmp w WHERE d.demand_header_id = w.demand_header_id;
• Listing demands referenced by MRP derived sales-order demands: SELECT m.demand_header_id FROM mrp_derived_so_demands m WHERE m.demand_header_id IS NOT NULL;
• Existence checks before upgrade or patching, using SELECT COUNT(*) FROM rla_demand_headers_all; to determine whether the obsolete object is present.

Because the module is obsolete, reporting built on this table is generally limited to migration validation and historical reconciliation rather than active operational reporting.

Related Objects

The metadata documents two tables that reference RLA_DEMAND_HEADERS_ALL via the DEMAND_HEADER_ID column:

• WMS_REPL_DEMAND_GTMP — a WMS replenishment global temporary table; join on WMS_REPL_DEMAND_GTMP.DEMAND_HEADER_ID = RLA_DEMAND_HEADERS_ALL.DEMAND_HEADER_ID.
• MRP_DERIVED_SO_DEMANDS — MRP derived sales-order demand records; join on MRP_DERIVED_SO_DEMANDS.DEMAND_HEADER_ID = RLA_DEMAND_HEADERS_ALL.DEMAND_HEADER_ID.
• RLA_DEMAND_HEADERS_PK — the primary key constraint enforcing uniqueness of DEMAND_HEADER_ID.

Additional related RLA demand-detail tables and APIs are not enumerated in the supplied metadata and should be confirmed in the data dictionary of the target release.