Search Results line_id_pk

Overview

RLM_INTERFACE_LINES_ALL is a staging and interface table in the Oracle Release Management (RLM) module of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. The table stores item-level and item-detail-level information associated with customer planning schedules, shipping schedules, and production sequenced schedules. It is populated by the EDI Inbound Gateway, which parses inbound electronic releases and schedules received from trading partners and writes the resulting records into this table for subsequent validation, matching, and consumption by the Release Management schedule processing programs.

The table is owned by the RLM schema and is documented as VALID within the ETRM repository. Its structure is intentionally wide, comprising 340 documented columns in the 12.2.2 physical schema, a characteristic shared with other EDI landing tables that must accommodate a large number of optional, partner-specific, and external-format attributes without schema modification. The heuristic Data Vault classification derived from the foreign key structure is standalone; from a modeling perspective, this suggests the table behaves primarily as a satellite or staging construct rather than as a persistent hub or link in an integration model. It captures transactional detail attached to a schedule header rather than acting as a master entity in its own right.

Key Information Stored

The surrogate primary key is LINE_ID, enforced through the LINE_ID_PK constraint. A documented unique index, RLM_LINES_INTERFACE_U1, covers the combination of LINE_ID and HEADER_ID, which serves as the principal business-key candidate and links each line back to its parent schedule header.

The most significant columns fall into several functional groups:

• Header and identity linkage: LINE_ID, HEADER_ID, LINE_NUMBER, LINE_SOURCE, LINE_REFERENCE, PARENT_LINK_LINE_REF, and LINK_TO_LINE_REF establish the line's identity and its position within the inbound message hierarchy.
• Item identification: INVENTORY_ITEM_ID, CUSTOMER_ITEM_ID (which carries a foreign key to MTL_CUSTOMER_ITEMS), CUSTOMER_ITEM_REVISION, CUSTOMER_ITEM_EXT, INVENTORY_ITEM_SEGMENT1 through INVENTORY_ITEM_SEGMENT20, and SCHEDULE_ITEM_NUM identify the ordered item and its flexible-attribute segments.
• Quantities and units: PRIMARY_QUANTITY, PRIMARY_UOM_CODE, ITEM_DETAIL_QUANTITY, SUBLINE_QUANTITY, SUBLINE_UOM_CODE, UOM_CODE, and the quantity type qualifiers QTY_TYPE_CODE and QTY_TYPE_CODE_EXT.
• Dates and scheduling: REQUEST_DATE, SCHEDULE_DATE, START_DATE_TIME, END_DATE_TIME, DATE_TYPE_CODE, DELIVERY_LEAD_TIME, CUST_PRODUCTION_SEQ_NUM, CUST_PRODUCTION_SEQ_NUM_BEG, and CUST_PRODUCTION_SEQ_NUM_END.
• Order and reference data: CUST_PO_NUMBER, CUST_PO_LINE_NUM, CUST_PO_DATE, CUST_PO_RELEASE_NUM, CUSTOMER_JOB, and CUST_PRODUCTION_LINE.
• Party and address information: SHIP_TO_ORG_ID, SHIP_FROM_ORG_ID, BILL_TO_SITE_USE_ID, INTRMD_SHIP_TO_ID, and the associated EXT address-suffix columns.
• Process control: PROCESS_STATUS tracks inbound processing state, while REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, and PROGRAM_UPDATE_DATE identify the concurrent request that created or last updated the row.
• Audit and extensibility: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, ATTRIBUTE1 through ATTRIBUTE15, and TP_ATTRIBUTE1 through TP_ATTRIBUTE15 for trading-partner-specific values.

Common Use Cases and Queries

The primary operational use case is troubleshooting and monitoring inbound EDI schedule loads. Developers and support analysts query the table by HEADER_ID to inspect all lines belonging to a specific inbound transmission, or filter on PROCESS_STATUS to identify records that failed validation or remain unprocessed. A typical pattern is:

SELECT LINE_ID, HEADER_ID, LINE_NUMBER, INVENTORY_ITEM_ID, CUSTOMER_ITEM_ID, PRIMARY_QUANTITY, PRIMARY_UOM_CODE, SCHEDULE_DATE, PROCESS_STATUS FROM RLM.RLM_INTERFACE_LINES_ALL WHERE HEADER_ID = :p_header_id ORDER BY LINE_NUMBER;

A second pattern joins to the customer item master to resolve customer part numbers into internal inventory items, which is the standard reconciliation performed before release lines are passed downstream into the scheduling engine:

SELECT l.LINE_ID, l.CUSTOMER_ITEM_EXT, l.CUSTOMER_ITEM_ID, m.INVENTORY_ITEM_ID FROM RLM.RLM_INTERFACE_LINES_ALL l, MTL_CUSTOMER_ITEMS m WHERE l.CUSTOMER_ITEM_ID = m.CUSTOMER_ITEM_ID AND l.PROCESS_STATUS = 'PENDING';

Reporting use cases include measuring inbound schedule volume by trading partner and date range, auditing demand across planning and production sequencing horizons, and verifying that production sequence ranges captured in CUST_PRODUCTION_SEQ_NUM_BEG and CUST_PRODUCTION_SEQ_NUM_END reconcile with the transmitted schedule. Because the table includes the concurrent program audit columns, it also supports tracing a set of interface lines back to the specific concurrent request and program that inserted them.

Related Objects

The table sits within a small but well-defined reference set. The documented foreign key relationship is to MTL_CUSTOMER_ITEMS, joined through CUSTOMER_ITEM_ID, which supplies the customer item cross-reference used to resolve transmitted part numbers. The most significant related objects are:

• MTL_CUSTOMER_ITEMS — referenced by CUSTOMER_ITEM_ID; resolves customer part numbers to internal inventory items.
• RLM_INTERFACE_HEADERS_ALL — the parent schedule header table, joined on HEADER_ID; carries trading partner and schedule-level attributes.
• MTL_SYSTEM_ITEMS_B — the inventory item master, joined on INVENTORY_ITEM_ID or via the INVENTORY_ITEM_SEGMENT columns.
• RLM_SCHEDULE_LINES — the validated release and schedule line table that receives data after interface processing; SCHEDULE_LINE_ID appears as a column here to support that linkage.
• RLM_INTERFACE_ERRORS — stores validation failures raised while processing rows from this table.
• HR_LOCATIONS_ALL / HZ_LOCATIONS — used to resolve the various party and address identifiers, including SHIP_TO_SITE_USE_ID and BILL_TO_SITE_USE_ID.
• EDI Inbound Gateway concurrent programs — the processing machinery that inserts into and consumes this table during schedule import.

Because the table is classified as standalone from a data vault perspective, no additional hub or link foreign keys are documented beyond the customer item reference; consumers should rely on the business columns above rather than on declared constraints when constructing joins.