Search Results so_ship_priorities_active_v




Overview
Explore in AI Chat

Overview

The SO_SHIP_PRIORITIES_ACTIVE_V view is an Oracle E-Business Suite (EBS) dictionary object owned by the APPS schema and registered under the Order Entry (OE) product family. It presents the set of currently active shipment priority values defined within Order Management. In both EBS 12.1.1 and 12.2.2 this view retains a VALID status and the same underlying definition, so behavior is consistent across releases.

Its role in reporting and integration is that of a lightweight lookup decoder. Rather than requiring developers or report authors to query SO_LOOKUPS directly and replicate the date-range and enabled-flag filtering logic, the view encapsulates that logic and exposes a clean list of shipment priorities that are valid "as of today." This makes it suitable for LOV-style integrations, BI Publisher data models, OAF/ADF list sources, and any custom interface that must validate or translate a shipment priority code into its user-facing meaning. Because the view derives its content from the SO_LOOKUPS translation table with a TRUNC(SYSDATE) predicate, its result set is time-sensitive: entries whose START_DATE_ACTIVE or END_DATE_ACTIVE window does not include the current date are automatically excluded.

Underlying Base Objects

The documented definition of the view selects from SO_LOOKUPS, which in the APPS schema is presented as a synonym referencing the Order Entry lookup table. The view applies three filters to that source:

  • LOOKUP_TYPE = 'SHIPMENT_PRIORITY', isolating the lookup set used specifically for shipment priorities.
  • ENABLED_FLAG = 'Y', restricting output to entries that are active/enabled.
  • A date-window predicate: TRUNC(SYSDATE) BETWEEN NVL(START_DATE_ACTIVE, TRUNC(SYSDATE)) AND NVL(END_DATE_ACTIVE, TRUNC(SYSDATE)), which permits records with missing start or end dates by defaulting them to the current date.

The ETRM metadata also lists FND_GLOBAL as a referenced base object. FND_GLOBAL is the standard EBS package that exposes session context such as USER_ID, RESP_ID, and ORG_ID; its inclusion generally reflects the multi-org or security context applied when the view is accessed through the APPS layer, and it does not alter the two-column result set described below. There are no joins to order, line, or delivery tables — the view is a pure lookup translation of the SO_LOOKUPS table.

Key Columns

  • SHIPMENT_PRIORITY — The descriptive text or "meaning" stored in SO_LOOKUPS.MEANING. This is the display value shown to users in forms and reports (for example, "High", "Standard", "Low").
  • SHIPMENT_PRIORITY_CODE — The underlying code stored in SO_LOOKUPS.LOOKUP_CODE. This is the value typically persisted on transaction tables and referenced by validation logic.

The columns are aliased so that consumers receive intuitive names rather than the raw MEANING/LOOKUP_CODE labels, simplifying query writing and integration mapping. Because the view projects only these two columns, it cannot be used to retrieve additional lookup attributes such as descriptions, tag values, or attribute columns.

Common Use Cases and Queries

Typical applications include populating a shipment priority selection list, resolving a stored code to its meaning in a custom report, and validating user-supplied priority values before they are written to Order Management tables.

To list all active shipment priorities:

  • SELECT shipment_priority, shipment_priority_code FROM apps.so_ship_priorities_active_v ORDER BY shipment_priority;

To translate a specific code into its meaning:

  • SELECT shipment_priority FROM apps.so_ship_priorities_active_v WHERE shipment_priority_code = :p_code;

To confirm that a code is currently valid during an interface or concurrent program:

  • SELECT COUNT(*) FROM apps.so_ship_priorities_active_v WHERE shipment_priority_code = :p_code;

Because the view is date-driven, integrations should not cache its output indefinitely; a priority that is valid today may expire if its END_DATE_ACTIVE passes. Reports requiring historical priorities should query SO_LOOKUPS directly without the date predicate.