Results for “to_location”

50+ results




Overview
Explore in AI Chat

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

MRP_INTER_LOCATIONS_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It is documented under the MRP (Master Scheduling/MRP) product family and is described in the ETRM metadata as the "Inter-Location Ship Methods view." The view consolidates the shipping relationships defined between inventory organizations and presents them together with human-readable location identifiers and descriptions for both the source and destination sides of each inter-org ship method. Because it resolves raw numeric location identifiers into displayable names, it is frequently used as a reporting and integration layer whenever an external system or concurrent program must translate internal location IDs into meaningful text.

The object carries a VALID status and carries no DML privileges; it is intended strictly for query and reporting purposes. Its most visible behavior is the resolution of LOCATION_CODE: when an HR location code exists it is returned, otherwise the view falls back to a truncated address value, ensuring that a display string is nearly always available.

Underlying Base Objects

The documented base objects behind MRP_INTER_LOCATIONS_V are:

  • MTL_INTERORG_SHIP_METHODS (synonym) — the driving table holding the from/to location IDs that define each inter-organization ship method.
  • HR_LOCATIONS (view) — supplies the internal LOCATION_CODE and DESCRIPTION attributes for both the from-location and to-location.
  • HZ_LOCATIONS (synonym) — supplies the ADDRESS1 fallback when no HR location code is present.
  • HR_GENERAL (package) — referenced as a supporting object, providing the seeded HR utility logic that resolves location display attributes.

The join logic is a multi-way outer join: HR_LOCATIONS and HZ_LOCATIONS are joined with the (+) outer-join operator to both the from and to location IDs on MTL_INTERORG_SHIP_METHODS. This guarantees that every ship method row survives even when a corresponding HR or HZ location record is missing, with NULLs propagated instead. The SELECT DISTINCT clause eliminates duplicate combinations that can arise from multiple matching location rows.

Key Columns

  • FROM_LOCATION_ID — numeric ID of the source (shipping) location drawn from the ship methods table.
  • FROM_LOCATION — display name of the source location. Produced by DECODE(HR1.LOCATION_CODE, NULL, SUBSTR(HZ1.ADDRESS1,1,20), HR1.LOCATION_CODE): the HR location code if present, otherwise the first 20 characters of the HZ address.
  • FROM_LOC_DESC — descriptive text for the source location, using the HR description or the first 50 characters of the HZ address as fallback.
  • TO_LOCATION_ID — numeric ID of the destination (receiving) location.
  • TO_LOCATION — display name of the destination location, resolved with the same DECODE pattern on the to-side HR/HZ records.
  • TO_LOC_DESC — descriptive text for the destination location.

The LOCATION_CODE attribute the user searched for appears indirectly through these DECODE expressions; it is the primary source of the FROM_LOCATION and TO_LOCATION display values and is the field most commonly filtered on in ad-hoc reporting.

Common Use Cases and Queries

Typical applications include validating inter-org shipping network configuration, populating cross-reference tables for supply chain integrations, and exposing shipment routing to downstream planning or OTM-style systems that cannot interpret numeric location IDs. Because the view abstracts the HR/HZ fallback logic, it spares developers from writing repetitive DECODE logic themselves.

A representative query listing all resolved ship methods is:

  • SELECT from_location_id, from_location, from_loc_desc, to_location_id, to_location, to_loc_desc FROM apps.mrp_inter_locations_v ORDER BY from_location, to_location;
  • SELECT * FROM apps.mrp_inter_locations_v WHERE from_location = :p_location_code; — filters on the resolved code rather than the numeric ID.
  • SELECT DISTINCT to_location, to_loc_desc FROM apps.mrp_inter_locations_v WHERE from_location_id = :p_org_id; — enumerates valid receiving destinations for a given source.

Because the object is a view with no INSTEAD-OF triggers documented, all access should be treated as read-only. Filtering on FROM_LOCATION or TO_LOCATION is efficient for ad-hoc extraction, but for high-volume joins the underlying MTL_INTERORG_SHIP_METHODS location IDs should be used to avoid function-based evaluation of the DECODE expressions. Oracle Proprietary, Confidential Information — Legal Notices apply.