Search Results schedule_header_id_pk

Overview

RLM_SCHEDULE_HEADERS_ALL is the master header table for Oracle Release Management (RLM), a supply-chain module that manages demand and release schedules exchanged between customers, suppliers, and manufacturing organizations. The table stores header-level details of each Release Management schedule, along with the customer- and supplier-level information carried on that schedule. The RLM Demand Processor writes to and maintains this table to preserve a current picture of incoming demand and releases, which downstream processes then explode into schedule lines, buckets, and demand records.

The object resides in the RLM schema and is documented in ETRM 12.1.1 / 12.2.2 with a physical schema of 152 columns. Its primary key is enforced through the SCHEDULE_HEADER_ID_PK constraint on HEADER_ID, with a unique index RLM_SCHEDULE_HEADERS_U1 also on HEADER_ID. Because the table carries ORG_ID and is an _ALL table, it is partitioned by operating unit for multi-org access. From a modeling perspective, the heuristic Data Vault classification of this object is standalone, mined from its foreign-key structure. Standalone classification suggests the table functions primarily as a hub-style anchor for schedule header identity, with descriptive attributes housed around it rather than participating heavily in link relationships.

Key Information Stored

The following columns carry the most analytical and operational weight:

• HEADER_ID – surrogate primary key and unique business-key candidate; the anchor for all schedule-level joins.
• CUSTOMER_ID – identifies the customer for whom the schedule was received.
• SUPPLIER_ID – identifies the supplier when the schedule is supply-facing.
• ORG_ID – operating unit that owns the schedule, enabling multi-org partitioning.
• SCHEDULE_TYPE and SCHEDULE_TYPE_EXT – classification of the schedule (e.g., planning, shipping, sequencer).
• SCHEDULE_PURPOSE and SCHEDULE_PURPOSE_EXT – business intent, such as original versus replacement.
• SCHED_HORIZON_START_DATE / SCHED_HORIZON_END_DATE – the validity window covered by the header.
• SCHED_GENERATION_DATE – date the schedule was produced at source.
• SCHEDULE_SOURCE and SCHEDULE_REFERENCE_NUM
– provenance and originating document reference.
• BUCKET_START_DATE / BUCKET_END_DATE / FLEX_BUCKET_CODE – bucket-level planning constraints.
• PROCESS_STATUS – lifecycle state used by the Demand Processor and import routines.
• INTERFACE_HEADER_ID – link back to the interface/staging row from which this header was created.
• RESP_SCHEDULE_ID – self-referencing pointer to a response schedule derived from this one.
• REQUEST_ID / PROGRAM_ID / PROGRAM_UPDATE_DATE – concurrent program context for traceability.
• Attribute and TP_ATTRIBUTE flex columns – DFF and trading-partner extensibility.

The customer and supplier _EXT columns (addresses, contacts, tax, currency) denormalize trading-partner details captured at schedule receipt, preserving the data as it appeared on the original transaction.

Common Use Cases and Queries

Typical reporting includes inbound schedule volume by customer, open schedule horizons, and processing backlogs. A representative query lists active schedules for an operating unit:

• SELECT header_id, customer_id, schedule_type, sched_horizon_start_date, sched_horizon_end_date FROM rlm_schedule_headers_all WHERE org_id = :org_id AND process_status = 'PROCESSED';
• Aging of unprocessed demand: filter on process_status <> 'PROCESSED' and compare sched_generation_date to SYSDATE.
• Traceability: join INTERFACE_HEADER_ID to the interface table and REQUEST_ID to concurrent request history to audit how a schedule entered the system.
• Response tracking: self-join on RESP_SCHEDULE_ID = HEADER_ID to pair original and response schedules.
• Bucket analysis: group by FLEX_BUCKET_CODE, bucket dates, and schedule_purpose.

Related Objects

Because its Data Vault classification is standalone (no FK dependencies mined), likely relationships are driven by application logic rather than enforced constraints. Significant related objects include:

• RLM_SCHEDULE_LINES_ALL – joins on HEADER_ID to explode the header into item lines.
• RLM_SCHEDULE_HEADERS_INTERFACE / interface table – linked via INTERFACE_HEADER_ID.
• PO_HEADERS_ALL / PO_RELEASES_ALL – customer and supplier identifiers connect to purchasing documents.
• HR_ALL_ORGANIZATION_UNITS – via ORG_ID for operating unit context.
• FND_CONCURRENT_REQUESTS – via REQUEST_ID for program traceability.
• RA_CUSTOMERS / AP_SUPPLIERS – via CUSTOMER_ID and SUPPLIER_ID for trading-partner detail.

No foreign-key relationships are documented in the ETRM metadata, so joins must be based on the shared business columns listed above.