Search Results get_so_number_status




Overview
Explore in AI Chat

Overview

POR_VIEW_REQS_PKG is a public PL/SQL package owned by APPS and classified as OTHER in the Oracle EBS ETRM repository. Its name reflects its purpose: it supplies the derivation and display logic behind the requisition viewing layer, most notably the POR_APPROVAL_STATUS_LINES_V view referenced in the package header comments. The package is defined with AUTHID CURRENT_USER and does not expose a documented PL/SQL API intended for external transactional use; instead it provides scalar lookup functions used by Oracle iProcurement and Purchasing inquiry pages to translate numeric foreign keys — header, line, approver, and personnel identifiers — into human-readable values displayed on requisition summary and approval status screens.

The package is referenced by twelve other packages, indicating it is a common utility layer consumed by requisition-facing modules. All of its documented entry points are self-contained functions that accept an identifier and return a single VARCHAR2 or NUMBER value, which makes it well suited to being called from within SQL in views as well as from forms-based triggers.

Key Procedures and Functions

Forty procedures and functions are documented. They fall into distinct functional groups.

  • Header-level display functions: GET_REQUESTER, GET_DELIVER_TO, GET_NOTE_TO_AGENT, and GET_REQ_TOTAL resolve requisition header attributes for the view. GET_REQUESTER and GET_DELIVER_TO return the display names for the requester and deliver-to party; GET_NOTE_TO_AGENT returns the free-text note intended for the buyer; GET_REQ_TOTAL returns the header value as a number.
  • Line-level accounting and project functions: GET_ACCOUNT_NUMBER, GET_PROJECT_NUMBER, GET_TASK_NAME, and GET_EXPENDITURE_TYPE each accept a req_line_id and return the corresponding distribution or project attribute. These are the functions most directly associated with the req_line_id search term, since they resolve the accounting and project context of an individual requisition line.
  • Line-level shipment and sales order functions: GET_SHIPMENT_NUMBER returns the shipment identifier for a line. GET_SO_NUMBER_STATUS returns the sales order number or its status text and includes an overloaded signature used when invoked from the Lifecycle page; a companion function, GET_SO_NUMBER_STATUS_CODE, formats a status code with line and order context. GET_SO_STATUS returns the overall sales order status for a line.
  • Header-level sourcing flags: IS_PLACEDONPO, IS_PLACEDONSO, and IS_PLACEDONNG indicate whether the requisition has been placed on a purchase order, a sales order, or is otherwise not yet grouped, respectively.
  • Approver functions: GET_APPROVER_NAME, GET_APPROVER_EMAIL, and GET_BUSINESS_GROUP_NAME resolve approver identity and context for the approval status view, based on the packed-in approver_id.
  • Supplier and internal helper functions: GET_SUPPLIER_NAME returns the supplier name for a header, and GETLINEINFO provides a consolidated line information helper.

Tables Accessed

The package reads from a broad set of APPS synonyms. Requisition and sourcing context is drawn from PO_HEADERS_ALL, PO_DISTRIBUTIONS_ALL, and POR_ITEM_ATTRIBUTE_VALUES. Project and expenditure data comes from PA_PROJECTS and PA_PROJECTS_ALL. Sales order status logic reads OE_ORDER_HEADERS_ALL and OE_ORDER_LINES_ALL. User and organizational data is resolved through FND_USER, PER_ALL_PEOPLE_F, PER_PHONES, HR_LOCATIONS_ALL_TL, FND_TERRITORIES_TL, and FINANCIALS_SYSTEM_PARAMS_ALL. FND_LOOKUP_VALUES supplies code-to-meaning translations, and FND_LOG_MESSAGES is available for debug logging.

Usage Notes

POR_VIEW_REQS_PKG is primarily invoked from Oracle iProcurement and Purchasing requisition inquiry and approval-status pages, and from the POR_APPROVAL_STATUS_LINES_V view described in the package header. Because each function takes a single identifier and returns a scalar, the package is also a common target for custom SQL and reporting that must present requisition header, line, project, or sales order context. Custom code should call these functions rather than reimplementing the underlying joins, since the package centralizes lookup, territory, and lifecycle-page handling logic — including the overloaded SO number status entry point used by the Lifecycle page.