Search Results rlm_interface_headers_n3

Overview

RLM.RLM_INTERFACE_HEADERS_ALL is the header-level interface table for Oracle Release Management (RLM), the EBS module that manages release management schedules across the demand chain. The table stores header-level details of release management schedules together with the customer and supplier information carried on those schedules. Its documented scope is public and its lifecycle status is active, with the display name "Release Management Headers Interface" and a business entity classification of RLM_SCHEDULE.

The table functions as a staging and interface surface rather than a purely transactional store. EDI Gateway feeds demand transactions into this table for Planning, Shipping, and Sequenced Schedules, meaning inbound EDI scheduling documents are decomposed into a header record here and corresponding line-level records in the companion interface table. From the interface layer, validated records are processed into the Live Release Management schedule tables for planning, scheduling, and order promising activities.

The documented storage location is the APPS_TS_TX_DATA tablespace with a PCT Free of 10, which places it among the transactional data objects of the Applications schema rather than reference or seed data. The heuristic Data Vault classification mined from the foreign-key structure is "standalone," indicating that the table can be modeled as an independent hub-like entity in a Data Vault design, anchored by its own generated identifier rather than being a pure dependent satellite of a parent schedule record.

The physical schema documented for 12.2.2 contains 152 columns, confirming the table's role as a wide, integration-oriented staging structure that accommodates both the standard EDI transaction-set fields and significant customer-extension and supplier-extension content.

Key Information Stored

The table is anchored by HEADER_ID, a sequence-generated NUMBER that uniquely identifies each interface header record and is enforced by the unique index RLM_HEADERS_INTERFACE_U1. HEADER_ID is the surrogate primary key of the table and is the column most commonly used as the join key from interface to downstream processing logic. The documented primary key is HEADER_ID_PK on HEADER_ID.

Business-key candidates, as documented by the unique index inventory, are limited to HEADER_ID itself; the remaining indexes are non-unique and therefore support lookup rather than identity enforcement. Notable among these are RLM_INTERFACE_HEADERS_N1 on SCHEDULE_HEADER_ID, RLM_INTERFACE_HEADERS_N2 on ECE_TP_LOCATION_CODE_EXT, RLM_INTERFACE_HEADERS_N3 on CUSTOMER_ID, RLM_INTERFACE_HEADERS_N4 on SCHEDULE_REFERENCE_NUM, RLM_INTERFACE_HEADERS_N5 on SCHED_HORIZON_START_DATE, and RLM_INTERFACE_HEADERS_N6 on CUST_NAME_EXT.

The most operationally significant columns include the following:

• HEADER_ID — sequence-generated unique identifier for the interface header record.
• SCHEDULE_HEADER_ID — the identifier of the associated release management schedule header; this column is documented as a foreign key to AR_CHARGE_SCHEDULE_HDRS and is indexed by RLM_INTERFACE_HEADERS_N1.
• SCHEDULE_TYPE and SCHEDULE_TYPE_EXT — the internal and customer-sent schedule type, distinguishing planning, shipping, and sequenced schedules.
• SCHEDULE_PURPOSE and SCHEDULE_PURPOSE_EXT — the internal and external schedule purpose, which drives downstream processing behavior.
• SCHEDULE_REFERENCE_NUM — the customer's schedule reference number, indexed for lookup.
• CUSTOMER_ID — the resolved EBS customer identifier, indexed by RLM_INTERFACE_HEADERS_N3.
• CUST_NAME_EXT and CUST_DESCRIPTION_EXT — the customer name and description as sent on the inbound document.
• SCHED_HORIZON_START_DATE and SCHED_HORIZON_END_DATE — the planning horizon covered by the schedule.
• SCHED_GENERATION_DATE — the date the schedule was generated by the customer or trading partner.
• ORG_ID — the operating unit owning the record, supporting multi-org security.
• PROCESS_STATUS — the current processing state of the interface row within the inbound workflow.
• ECE_TP_LOCATION_CODE_EXT — the trading partner location code used by EDI Gateway, indexed by RLM_INTERFACE_HEADERS_N2.
• SUPPLIER_ID and SUPPLIER_NAME_EXT — supplier-side identifiers for schedules that involve supplier demand.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE — the concurrent program context that created or last updated the record.

Extensive customer and supplier address blocks are stored directly on the header, including CUST_ADDRESS_1_EXT through CUST_ADDRESS_9_EXT, CUST_CITY_EXT, CUST_COUNTRY_EXT, CUST_POSTAL_CD_EXT, CUST_STATE_EXT, CUST_PROVINCE_EXT, and their SUPPLIER_-prefixed counterparts. Contact details are held in HEADER_CONTACT_VALUE_1, HEADER_CONTACT_VALUE_2, HEADER_CONTACT_TEL_1_EXT, HEADER_CONTACT_TEL_2_EXT, HEADER_CONTACT_FAX_1_EXT, HEADER_CONTACT_FAX_2_EXT, HEADER_CONTACT_EMAIL_1_EXT, and HEADER_CONTACT_EMAIL_2_EXT. A standard multi-org assignment set — ATTRIBUTE_CATEGORY, ATTRIBUTE1 through ATTRIBUTE15, and TP_ATTRIBUTE_CATEGORY with TP_ATTRIBUTE1 through TP_ATTRIBUTE15 — provides descriptor flexibility, while the audit columns LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN follow the standard EBS WHO-column convention.

In a Data Vault sense, the recommended modeling suggestion is to treat this table as a standalone hub keyed on HEADER_ID, with the descriptive address, contact, and audit attributes forming a satellite. The SCHEDULE_HEADER_ID reference to AR_CHARGE_SCHEDULE_HDRS could be represented as a link to the schedule hub if the modelling initiative extends into the Receivables schedule domain.

Common Use Cases and Queries

The primary use case is monitoring and troubleshooting inbound EDI demand. Because EDI Gateway populates this table before live schedule records are created, support teams query it to determine why a schedule did or did not process. A typical pattern filters on PROCESS_STATUS and the trading partner location:

• SELECT HEADER_ID, SCHEDULE_REFERENCE_NUM, CUSTOMER_ID, PROCESS_STATUS, SCHED_GENERATION_DATE FROM RLM.RLM_INTERFACE_HEADERS_ALL WHERE PROCESS_STATUS = 'ERROR' ORDER BY CREATION_DATE DESC;
• SELECT h.HEADER_ID, h.SCHEDULE_REFERENCE_NUM, h.SCHED_HORIZON_START_DATE, h.SCHED_HORIZON_END_DATE FROM RLM.RLM_INTERFACE_HEADERS_ALL h WHERE h.CUSTOMER_ID = :p_customer_id AND h.SCHED_HORIZON_START_DATE >= :p_start_date;
• SELECT HEADER_ID, SCHEDULE_TYPE, SCHEDULE_PURPOSE FROM RLM.RLM_INTERFACE_HEADERS_ALL WHERE ECE_TP_LOCATION_CODE_EXT = :p_location_code;

Because the table is the header half of a header-line interface pair, the most frequent join is to the line-level interface table on HEADER_ID, producing a complete inbound document view. Reporting users also join to the customer master on CUSTOMER_ID to reconcile the CUST_NAME_EXT value received on the document against the internally resolved customer name, which is a standard EDI trading partner data-quality check. Horizon-based queries using SCHED_HORIZON_START_DATE, indexed by RLM_INTERFACE_HEADERS_N5, support capacity and demand reporting across a rolling window.

Data reconciliation between the interface header and the resulting live schedule header is another common exercise, executed by joining on SCHEDULE_HEADER_ID to AR_CHARGE_SCHEDULE_HDRS once processing has completed. Concurrent request tracing uses REQUEST_ID, PROGRAM_ID, and PROGRAM_APPLICATION_ID to identify the specific EDI inbound program and run that created each record.

Related Objects

The following objects are most significant to the operation of RLM_INTERFACE_HEADERS_ALL:

• AR_CHARGE_SCHEDULE_HDRS — referenced by the documented foreign key from RLM_INTERFACE_HEADERS_ALL.SCHEDULE_HEADER_ID; the live schedule header that the interface record resolves to after processing.
• RLM_INTERFACE_LINES_ALL — the companion line-level interface table, joined on HEADER_ID to reconstruct the full inbound document.
• The RLM live schedule headers table — the destination of validated interface headers during the Release Management schedule creation process.
• EDI Gateway inbound processing objects — the components that populate this table for Planning, Shipping, and Sequenced Schedule demand transactions.
• Customer master objects — joined on CUSTOMER_ID to validate CUST_NAME_EXT and the extended address attributes.
• Trading partner and location objects referenced by ECE_TP_LOCATION_CODE_EXT and ECE_TP_TRANSLATOR_CODE.
• Supplier master objects — joined on SUPPLIER_ID to resolve the supplier-side header attributes used on supplier schedules.
• FND concurrent program request objects — joined on REQUEST_ID for inbound program tracing.

Access to the table is ordinarily read-only for reporting and support users; writes occur through the EDI Gateway and Release Management processing programs. Any direct manipulation should be avoided in a production environment because the table participates in the inbound integration flow for demand scheduling.