Search Results ship_to_year

Overview

The FTE_PTRK_TOKENS_V view is a reporting and integration object owned by the APPS schema within the FTE – Transportation Execution product family of Oracle E-Business Suite 12.1.1 and 12.2.2. It presents a denormalized, flat representation of trip stop movement data derived from delivery legs, trip stops, and location definitions. The view is primarily intended to expose shipment origin and destination attributes alongside formatted scheduling timestamps, allowing downstream applications, BI Publisher reports, and integration interfaces to consume trip-level logistics data without joining multiple WSH tables manually.

The name "PTRK_TOKENS" reflects a token-based presentation pattern, in which each row exposes discrete, named columns (tokens) that can be mapped directly into report templates or message payloads. The view is documented as VALID and is available in both 12.1.1 and 12.2.2 environments, though the underlying referenced objects are consistently the WSH synonyms described below.

Underlying Base Objects

The view is defined over three documented base objects, referenced through public synonyms in the APPS schema:

• WSH_DELIVERY_LEGS (synonym) — supplies the DELIVERY_LEG_ID and links the pickup stop to the drop-off stop through PICK_UP_STOP_ID and DROP_OFF_STOP_ID.
• WSH_TRIP_STOPS (synonym) — appears twice in the definition, aliased as STOPS1 (origin/pickup) and STOPS2 (destination/drop-off), and provides the actual departure and arrival dates used to derive the ship-from and ship-to tokens.
• WSH_LOCATIONS (synonym) — also appears twice, aliased as LOC1 (destination) and LOC2 (origin), supplying postal code, city, state, and country attributes.

The join path is: LOC1.WSH_LOCATION_ID = STOPS1.STOP_LOCATION_ID, LOC2.WSH_LOCATION_ID = STOPS2.STOP_LOCATION_ID, LEGS.PICK_UP_STOP_ID = STOPS1.STOP_ID, and LEGS.DROP_OFF_STOP_ID = STOPS2.STOP_ID. Note that the origin location is sourced from STOPS1 and the destination from STOPS2, while the geographic aliases are reversed relative to their stop aliases in the view text.

Key Columns

The view exposes seventeen columns. The most significant for the user's search term is SHIP_FROM_DAY, which is derived as TO_CHAR(STOPS1.ACTUAL_DEPARTURE_DATE, 'DD') — the day-of-month component of the actual departure from the origin stop. It is complemented by SHIP_FROM_YEAR, SHIP_FROM_MONTH, and a fully formatted SHIP_FROM_DATE string in YYYY-MM-DD-HH24:MI:SS format. Parallel tokens exist for the destination: SHIP_TO_DATE, SHIP_TO_YEAR, SHIP_TO_MONTH, and SHIP_TO_DAY, all derived from STOPS2.ACTUAL_ARRIVAL_DATE.

Identifier and geographic columns include DELIVERY_LEG_ID, DESTINATION_POSTAL_CODE, DESTINATION_CITY, DESTINATION_STATE, DESTINATION_COUNTRY_CODE, and the mirrored origin equivalents. Because all date tokens are returned as character strings, sorting by SHIP_FROM_DAY alone is not chronologically meaningful; the composite SHIP_FROM_DATE string should be used instead.

Common Use Cases and Queries

Typical scenarios include in-transit visibility reports, carrier performance analysis segmented by departure day, and integration extracts feeding external tracking systems. A representative query filtering on the searched token is:

• SELECT delivery_leg_id, origin_city, destination_city, ship_from_date, ship_from_day FROM fte_ptrk_tokens_v WHERE ship_from_day = '15';
• SELECT ship_from_year, ship_from_month, COUNT(*) FROM fte_ptrk_tokens_v GROUP BY ship_from_year, ship_from_month;
• SELECT delivery_leg_id, origin_postal_code, destination_postal_code, ship_from_date, ship_to_date FROM fte_ptrk_tokens_v WHERE ship_from_date BETWEEN :from_date AND :to_date;

Because the view performs no filtering of its own, date and status predicates should be applied by the calling query. Reports requiring actual stop-level detail should join back to WSH_TRIP_STOPS on the underlying stop identifiers.