Search Results get_party_vendor_name

Overview

APPS.PO_INQ_SV is a Purchasing inquiry service package body in Oracle E-Business Suite, shipped under the APPS schema and classified as OTHER within the ETRM repository. It underpins the read-only inquiry layer used by Oracle Purchasing and related modules to resolve display values, descriptive attributes, and security context for purchasing documents without modifying transactional data. The package exposes thirty-three documented procedures and functions, making it a shared service utility consumed broadly across the E-Business Suite: the ETRM metadata records that it is referenced by thirty-nine other packages. Its source header identifies the file as POXPOVPB.pls and records an "Agreement R12" instrumentation block that initialises the package name constant, log header prefix, and debug flags sourced from PO_DEBUG, indicating the package participates in the standard Oracle Purchasing debug and logging framework.

Key Procedures and Functions

The documented program units fall into several functional groups:

• NAME – the package's identifier routine, establishing the package designation used in logging and diagnostics.
• GET_FUNC_CURRENCY_ATTRIBUTES – returns functional currency attribute information used when displaying monetary values on purchasing inquiry screens.
• GET_SOURCE_INFO – retrieves sourcing information associated with a purchasing document, supporting the inquiry display of supplier and sourcing context.
• GET_TYPE_NAME – resolves the descriptive type name for a purchasing document type or subtype code.
• GET_RATE_TYPE – returns the currency rate type applicable to a document, used in currency conversion display logic.
• GET_VENDOR_NAME – resolves a supplier name from supplier identifiers for display purposes.
• GET_PARTY_VENDOR_NAME – resolves vendor naming through the Trading Community Architecture party model, accommodating the party-based supplier representation.
• GET_VENDOR_EMAIL – returns the e-mail address associated with a supplier, enabling inquiry forms and notification logic to present or use vendor contact e-mail information without direct table access.

The package body also contains private helper logic, including a local procedure GET_LOOKUP_DSP that translates a lookup type and code into a displayed field value, and GET_ACTION_HISTORY_VALUES, which populates action history attributes such as subtype, preparer, type name, document number, and security level and hierarchy from the purchasing document headers view and document types table. As with all packaged APIs of this classification, parameter signatures should be confirmed against the deployed source in the target instance.

Tables Accessed

The package reads from a defined set of APPS synonyms. Supplier and party data derive from AP_SUPPLIERS, HZ_PARTIES, and HZ_PARTY_USG_ASSIGNMENTS, supporting vendor name and vendor e-mail resolution. Purchasing document data comes from PO_HEADERS_ALL, and security context is obtained via po_document_types in conjunction with PO_DOCUMENT_HEADERS_VIEW within the action history routine. Currency handling uses FND_CURRENCIES, GL_DAILY_CONVERSION_TYPES, FINANCIALS_SYSTEM_PARAMETERS, and FINANCIALS_SYSTEM_PARAMS_ALL. Human resources and manufacturing reference data are read from HR_ALL_ORGANIZATION_UNITS, HR_ALL_ORGANIZATION_UNITS_TL, BOM_DEPARTMENTS, BOM_RESOURCES, and BOM_STANDARD_OPERATIONS. Application user information is read from FND_USER, and payment terms from AP_TERMS. The package is an inquiry service and should be treated as read-only with respect to these objects.

Usage Notes

PO_INQ_SV is typically invoked from Oracle Purchasing inquiry forms and related user interface components, and programmatically from other PL/SQL packages, to resolve display values rather than to perform transactional updates. Because it is referenced by thirty-nine other packages, changes to its behaviour can have wide-reaching effects, and customisations should avoid altering documented signatures. In EBS 12.1.1 and 12.2.2 the file header revision (120.3) indicates stability across these releases. Developers calling GET_VENDOR_EMAIL or other functions directly should handle the NO DATA FOUND and TOO MANY ROWS exceptions that are typical of single-row lookups, and should ensure the caller has execute privilege on the package in the APPS schema.