Search Results get_wip_number

Overview

ICX_GET_ORDER is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and registered with a status of VALID in the ETRM repository. It belongs to the ICX (Oracle iProcurement / Internet Commerce Exchange) product family and is classified as an OTHER API rather than a formal public interface. Its business purpose is to resolve the originating source document number for a given supply or demand transaction. In the EBS supply chain model, a single inventory or procurement activity can trace back to a purchase order, a requisition, a sales order, or a work order entity. ICX_GET_ORDER centralizes the lookup logic that maps a transaction or line identifier to the correct human-readable document number for each of these source types, so that calling components do not have to embed four separate query paths.

The package is a small, tightly scoped utility. It exposes four documented procedures and depends only on SYS.STANDARD at the database level, plus the application tables listed below. It is referenced by exactly one other package and by the view ICX_MTL_SUPPLY_DEMAND_V, which confirms its role as a supporting lookup layer behind supply-and-demand reporting and iProcurement display logic rather than a standalone business transaction API.

Key Procedures and Functions

• GET_PO_NUMBER — Returns the purchase order number associated with the supplied identifier. This is the procurement-side lookup used when a demand or receipt line must be traced back to its originating purchase order.
• GET_REQ_NUMBER — Returns the requisition number for the supplied identifier, covering the pre-purchase-order stage of the procurement cycle.
• GET_SO_NUMBER — Returns the sales order number, supporting order-management and fulfillment scenarios where the source document is a customer order rather than a procurement document.
• GET_WIP_NUMBER — Returns the work in process entity number, covering manufacturing supply and demand where the source document is a discrete job or repetitive schedule.

The four procedures deliberately mirror one another in purpose: each translates an internal key into the document number that an end user recognizes. No public parameter lists are documented in the ETRM extract, and they should not be assumed; integrators must inspect the package specification in the target instance before calling these routines directly.

Tables Accessed

The package reads the following base tables through APPS synonyms:

• PO_HEADERS_ALL — source of purchase order header information, including the PO number returned by GET_PO_NUMBER.
• PO_REQUISITION_HEADERS_ALL — source of requisition header information for GET_REQ_NUMBER.
• MTL_SALES_ORDERS — source of sales order information used by GET_SO_NUMBER.
• WIP_ENTITIES — source of work in process entity information used by GET_WIP_NUMBER.

All four appear to be read-only reference lookups. No insert, update, or delete activity is implied by the documented dependency list, which is consistent with the package's narrow role as a number-resolution helper. Because the table list is limited to headers and entities, the package is inexpensive to invoke and safe to call from reporting and view definitions.

Usage Notes

ICX_GET_ORDER is typically invoked indirectly rather than called by end users. Its single documented dependent package and the view ICX_MTL_SUPPLY_DEMAND_V indicate that it is consumed by supply-and-demand reporting logic, which surfaces source document numbers to iProcurement and inventory inquiry pages. In Oracle EBS 12.1.1 and 12.2.2, such views are commonly queried by Oracle Forms-based inquiry screens, OAF pages, and concurrent programs that populate supply/demand or replenishment output.

Custom code may call the four procedures directly when building its own supply/demand report and needs a consistent document-number derivation. Because the package is classified as OTHER and is not a published, versioned interface, customizations that depend on it should be treated as instance-specific. Oracle does not guarantee signature stability for non-public APIs, so any direct call should be wrapped and validated against the package specification in the deployed environment. Where possible, consumers should query ICX_MTL_SUPPLY_DEMAND_V so that number resolution remains Oracle-managed.