Search Results mst_snapshot_task_util




Overview
Explore in AI Chat

Overview

MST_SNAPSHOT_TASK_UTIL is a utility package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Oracle Transportation Management / Logistics Execution (MST) product family, specifically the snapshot and audit reporting subsystem. The package provides shared helper logic used by snapshot-based audit reports and by the views that expose snapshot task data to downstream consumers. Its classification as a UTIL object indicates that it is not a public business API; instead, it encapsulates low-level lookups and status derivations that would otherwise be duplicated across the surrounding MST packages and views. The package status is VALID, and it depends only on the SYS.STANDARD package, meaning it has no direct dependency on other APPS packages at the specification level. It is, however, referenced by several MST objects, including MST_AUDIT_REP_EXCP and the views MST_FTE_MOVES_V, MST_VIO_FACILITY_CALENDAR_V, and MST_WSH_TOPMOST_PACKAGES_V, which confirms its role as a shared dependency layer for snapshot and audit reporting.

Key Procedures and Functions

The ETRM documentation records six procedures and functions within MST_SNAPSHOT_TASK_UTIL. Parameter lists are not published in the metadata, so only their functional intent is described here.

  • LOG_MESSAGE — Writes diagnostic or progress messages to the database message log. This is the standard debugging and traceability hook used by snapshot task processing to record execution state for later review by support and administrators.
  • GET_PHASE_STATUS_CODE — Returns the status code associated with a snapshot task phase. This allows callers to evaluate the current state of a snapshot run without duplicating status-decoding logic.
  • GETCALENDAR — Retrieves calendar information, resolving the appropriate calendar definition for a given context. Calendars are essential when computing shipment, trip, and facility availability dates.
  • GETDELIVERYID — Returns the delivery identifier associated with the supplied context. This is used to relate shipment detail records back to their owning WSH delivery.
  • GETCMVEHICLETYPE — Returns the vehicle type derived from transportation data. This supports capacity, compliance, and audit reporting where vehicle classification is required.
  • GET_DEL_OSP_FLAG — Returns the delivery outbound/outsourced processing (OSP) indicator flag. This flag influences whether a delivery is treated as internally executed or handled by an external party in audit evaluations.

Tables Accessed

The package references the following APPS synonyms: BOM_CALENDAR_DATES and WSH_CALENDAR_ASSIGNMENTS supply the calendar dates and assignments used by GETCALENDAR; FTE_TRIP_MOVES and FTE_VEHICLE_TYPES provide trip movement and vehicle type data for GETCMVEHICLETYPE; WSH_DELIVERY_DETAILS, WSH_DELIVERY_ASSIGNMENTS, and WSH_NEW_DELIVERIES form the delivery domain used by GETDELIVERYID and GET_DEL_OSP_FLAG; WSH_TRIPS supports trip-level lookups; HZ_CUST_ACCOUNTS and HZ_RELATIONSHIPS resolve trading partner and relationship information used in audit exception reporting; WSH_LOCATION_OWNERS identifies location ownership for compliance checks; and FND_CONCURRENT_REQUESTS links snapshot task execution to the concurrent request that spawned it, enabling LOG_MESSAGE and phase status tracking. The breadth of these references confirms the package's role as a read-oriented utility layer rather than a transactional owner of data.

Usage Notes

MST_SNAPSHOT_TASK_UTIL is invoked indirectly rather than directly by end users. The documented dependency list shows that MST_AUDIT_REP_EXCP and the views MST_FTE_MOVES_V, MST_VIO_FACILITY_CALENDAR_V, and MST_WSH_TOPMOST_PACKAGES_V reference this package. Consequently, the package executes whenever those views are queried or the audit exception report is run, and whenever snapshot task submission invokes LOG_MESSAGE or GET_PHASE_STATUS_CODE. Customizations that call these procedures should treat the package as a stable but internal utility: signature changes are not part of a published API contract, and behavior may shift between 12.1.1 and 12.2.2. Because its only declared dependency is SYS.STANDARD, the package is comparatively low-risk to install and compile, but its output depends on the correctness of the snapshot, delivery, calendar, and trading partner data supplied by the calling environment.