Search Results origin_table




Overview
Explore in AI Chat

Overview

RLM_SCHEDULE_DATES_V is a VALID Oracle Application Object Library view owned by the APPS schema within the RLM (Release Management) product family. Its purpose is to consolidate shipment scheduling date and organizational data from two distinct sources — native schedule lines and interface lines — into a single, query-ready result set. The view is a UNION-based construct: it draws rows from schedule lines and interface lines and tags each row with an ORIGIN_TABLE literal ('SCHEDULE' or 'INTERFACE') so that downstream consumers can distinguish the provenance of every record. Because it is a view rather than a table, it stores no data of its own and inherits the integrity and security characteristics of the objects beneath it.

In the EBS 12.1.1 and 12.2.2 reporting and integration layers, this view serves as an abstraction over the disjoint scheduling tables. Rather than requiring report authors or interfaces to write conditional logic across multiple line tables, the view normalizes the union and exposes a consistent column projection, including the ORIGIN_TABLE discriminator, external customer organization identifiers, internal organization identifiers, address identifiers, and a start date/time. This makes it suitable for shipment scheduling, release management dashboards, and integration extracts that must reconcile scheduled versus interfaced demand.

Underlying Base Objects

The ETRM 12.2.2 metadata documents the following base objects referenced by RLM_SCHEDULE_DATES_V:

  • RLM_INTERFACE_LINES_ALL (SYNONYM) — the interface line table, supplying rows in the second UNION branch where PROCESS_STATUS is not equal to 5 (i.e., not fully processed).
  • RLM_SCHEDULE_INTERFACE_HDR_V (VIEW) — a header view joined on HEADER_ID (and additionally on SCHEDULE_HEADER_ID in the third UNION branch) that contributes the ORIGIN_TABLE value used for filtering.
  • RLM_SCHEDULE_LINES_ALL (SYNONYM) — the native schedule lines table, supplying rows in the first UNION branch and, under certain conditions, in the third branch where schedule lines satisfy a matching schedule header.

The UNION ALL semantics are effectively deduplicated by the DISTINCT keyword applied to each branch. All branches are constrained so that the ORIGIN_TABLE value from the header view matches the literal projected for that branch, ensuring internal consistency between the row source and its provenance tag. The final ORDER BY clause sorts on columns 3 through 7 (customer ship-from, ship-from org, ship-to org, customer ship-to, and ship-to address), giving deterministic output ordering.

Key Columns

  • HEADER_ID — the primary grouping identifier for the schedule or interface header to which the line belongs.
  • ORIGIN_TABLE — a literal discriminator returned as 'SCHEDULE' or 'INTERFACE', indicating whether the row originates from the native schedule lines or the interface lines. This is the column most directly associated with the "origin_table" search term.
  • CUST_SHIP_FROM_ORG_EXT and CUST_SHIP_TO_EXT — external customer organization identifiers for the ship-from and ship-to parties.
  • SHIP_FROM_ORG_ID and SHIP_TO_ORG_ID — internal organization identifiers for the shipping and receiving organizations.
  • SHIP_TO_ADDRESS_ID — the address identifier associated with the ship-to location.
  • START_DATE_TIME — the scheduled or interfaced start date/time for the line.

Common Use Cases and Queries

Typical uses include reconciliation reports comparing native schedules against interfaced demand, operational dashboards showing upcoming scheduled shipments, and integration extracts that must deliver a unified scheduling feed. A representative query filtering by provenance is:

  • SELECT header_id, origin_table, cust_ship_to_ext, ship_to_org_id, start_date_time FROM apps.rlm_schedule_dates_v WHERE origin_table = 'SCHEDULE' ORDER BY start_date_time;
  • SELECT header_id, cust_ship_from_org_ext, cust_ship_to_ext, ship_to_address_id, start_date_time FROM apps.rlm_schedule_dates_v WHERE origin_table = 'INTERFACE';
  • SELECT origin_table, COUNT(*) FROM apps.rlm_schedule_dates_v GROUP BY origin_table;

Because the view applies DISTINCT and joins through RLM_SCHEDULE_INTERFACE_HDR_V, consumers should expect only lines whose headers are properly represented in the interface header view. Queries filtering on ORIGIN_TABLE benefit from the sorted column order but should still be validated against the underlying RLM_INTERFACE_LINES_ALL PROCESS_STATUS logic, since processed interface lines (PROCESS_STATUS = 5) are deliberately excluded from the second branch and surfaced instead via schedule lines in the third branch.