Search Results shipment_schedule_number




Overview
Explore in AI Chat

Overview

ONT_UPGRADE_EXCEPTION_REPORT is an Oracle Order Management (ONT) helper package owned by the APPS schema. As its name indicates, it supports the upgrade exception reporting infrastructure used when order data is migrated or upgraded between releases of Oracle E-Business Suite, including the 12.1.1 to 12.2.2 transition. During an upgrade, shipment schedules and their associated line numbers may not survive the transformation intact, so the upgrade process needs a consistent, deterministic way of re-deriving or reporting the original line and shipment schedule numbering. This package provides exactly that capability: small, side-effect-free PL/SQL functions that compute line number and shipment schedule number values from identifier inputs. Because the package is declared AUTHID CURRENT_USER, its functions execute with the privileges of the calling session rather than the definer, which is appropriate for a utility package invoked from upgrade scripts, concurrent programs, and diagnostic queries run by the APPS user. The source header identifies the file as OEXNUPUS.pls with a 2005-era revision, placing the package in the older Order Management upgrade toolset that has been carried forward into the 12.2 code line.

Key Procedures and Functions

The documented interface consists of three functions, each with the same four optional IN parameters covering parent line ID, service parent line ID, shipment schedule line ID, and line number, and each returning a NUMBER. All three are declared with PRAGMA RESTRICT_REFERENCES using WNDS (writes no database state) and WNPS (writes no package state), confirming they are pure read-only computations suitable for use inside SQL statements and other restricted contexts.

  • BASE_LINE_NUMBER — Derives the base (top-level) line number for an order line, resolving the numbering from the supplied parent line identifiers and fallback line number.
  • SHIPMENT_SCHEDULE_NUMBER — Derives the shipment schedule number for a given shipment schedule line, using the parent line context and the shipment schedule line ID. This is the function referenced by the user search term "shipment_schedule_number" and is the most directly relevant entry point for shipment schedule numbering questions.
  • OPTION_LINE_NUMBER — Derives the option line number, used for option-class or configured lines that hang beneath a parent line in the order line hierarchy.

No procedures are documented; the package exposes only these three functions.

Tables Accessed

The only documented table reference is SO_LINES_ALL, accessed through an APPS synonym. SO_LINES_ALL is the base Order Management table holding order line definitions, including line numbers, parent line relationships, and shipment schedule linkage. The functions use it to look up the identifiers needed to reconstruct or report the correct numbering for each line type. Although the functions are marked as writing no database state, they read line data to resolve the numbering hierarchy. For a package of this vintage, it is plausible that the functions are also designed to operate purely on the passed-in parameters; the documented table reference should be treated as the identified dependency in the ETRM metadata rather than an exhaustive statement of every query path.

Usage Notes

This package is not an application-facing API in the sense of order entry or shipping transactions. It is an internal upgrade utility. Typical invocation patterns include upgrade driver scripts run during the 11i-to-12 or 12.1-to-12.2 upgrade that must validate or renumber order lines and shipment schedules, concurrent programs that produce upgrade exception reports, and custom diagnostic SQL written by technical consultants investigating numbering discrepancies after an upgrade. The search term "shipment_schedule_number" maps directly to the SHIPMENT_SCHEDULE_NUMBER function, so a user searching that phrase is most likely troubleshooting a shipment schedule numbering problem surfaced during an upgrade.

Because the functions carry WNDS and WNPS pragmas, they can be called from SQL SELECT statements and PL/SQL without violating restricted-call rules. The ETRM metadata records zero packages referencing ONT_UPGRADE_EXCEPTION_REPORT, indicating it sits at the leaf of the dependency tree and is called directly rather than chained from other PL/SQL APIs. Custom code should therefore call the functions explicitly rather than expecting another package to invoke them on its behalf.