Search Results delivered_to




Overview

FTE_LOAD_SCHEDULES_V is a reporting and integration view within the Oracle E-Business Suite Transportation Execution (FTE) module. It exposes header-level information about load schedules — the pre-defined, recurring transportation movements that FTE uses to generate loads and trips across a planner's network. The view presents a denormalized, presentation-ready projection of load schedule data, joining schedule attributes with carrier, lane, mode of transport, and document-level details so that downstream reports and interfaces do not need to reconstruct those relationships themselves. Because it flattens operational identifiers (LOAD_ID, LOAD_SCHEDULE_ID, LANE_ID, CARRIER_ID) alongside human-readable names (LOAD_SCHEDULE_NAME, LANE_NAME, CARRIER_NAME), it is well suited for both user-facing inquiries and outbound integration extracts. Note that the ETRM metadata records this view as "Not implemented in this database" and lists no documented referenced base objects, so its availability depends on the specific FTE patch level and configuration in a given environment.

Underlying Base Objects

Per the documented view text, FTE_LOAD_SCHEDULES_V is defined over a single base table, FTE_LOAD_SCHEDULES. All non-derived columns in the view map directly to columns on that table. The only transformations applied in the SELECT are explicit TO_CHAR conversions that format the date-time columns DEPARTURE_DATE, ARRIVAL_DATE, DELIVERY_DATE, RECEIPT_DATE, and SHIP_DATE using the 'DD-MM-YYYY HH24:MI:SS' mask. This means the view returns date values as formatted character strings rather than native DATE datatypes — an important consideration for any query that performs date arithmetic or range filtering at the database level. EST_DEPARTURE_DATE and EST_ARRIVAL_DATE are surfaced without this masking. The ETRM documentation lists no additional base objects, so the view is a straightforward single-table projection with no documented joins to lane, carrier, or stop master tables, despite the presence of denormalized name columns such as LANE_NAME and CARRIER_NAME, which are stored on the schedule record itself.

Key Columns

Common Use Cases and Queries

Typical uses include operational dashboarding of recurring schedules, reconciliation of load generation against schedule definitions, and outbound extracts feeding carrier booking or visibility platforms. Because the date columns are pre-formatted strings, filters should be applied against the underlying base table when precise date logic is required.

Retrieve all attributes for a known schedule:

SELECT * FROM FTE_LOAD_SCHEDULES_V WHERE LOAD_SCHEDULE_ID = :p_schedule_id;

List active schedules by carrier and lane for a reporting period:

SELECT LOAD_SCHEDULE_NAME, CARRIER_NAME, LANE_NAME, MODE_OF_TRANSPORTATION, DEPARTURE_DATE, STATUS_CODE FROM FTE_LOAD_SCHEDULES_V WHERE CARRIER_ID = :p_carrier AND STATUS_CODE = 'ACTIVE' ORDER BY LOAD_SCHEDULE_NAME;

Reconcile commercial terms for schedules tied to a quotation:

SELECT LOAD_SCHEDULE_ID, QUOTATION_NUMBER, FOB_CODE, FREIGHT_TERMS_CODE, PRICE, CURRENCY FROM FTE_LOAD_SCHEDULES_V WHERE QUOTATION_NUMBER IS NOT NULL;

For date-sensitive analysis, query FTE_LOAD_SCHEDULES directly and apply native date predicates, or convert the formatted strings explicitly in the calling report.