Search Results po_pdoi_invalid_vendor

Overview

PO_VENDORS_SV1 is a supplier validation server-side PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. Its role is to centralize validation logic for supplier (vendor) records used throughout the Oracle Purchasing and Payables modules. The package exposes an API classified as OTHER within the ETRM repository, and its primary documented entry point is the function val_vendor_info, which validates a vendor identifier, vendor site, vendor site type, and vendor contact against the supplier validation views maintained by Purchasing. When validation fails, the function populates an OUT error code and returns FALSE, allowing the caller to reject the offending row or record. The package is referenced by one additional package in the ETRM inventory, confirming that it functions as a shared validation utility rather than a standalone program. In practice, it sits beneath higher-level supplier entry and supplier import flows, enforcing referential integrity against the current state of the supplier master before downstream processing proceeds.

Key Procedures and Functions

• val_vendor_info — The documented function that performs the core supplier validation. It accepts a vendor identifier, a vendor site type, a vendor site identifier, and a vendor contact identifier, together with an IN OUT error code parameter, and returns a BOOLEAN result of TRUE (valid) or FALSE (invalid). Its logic proceeds through distinct checkpoints tracked by an internal x_progress variable: it first confirms the vendor exists in po_suppliers_val_v, returning error code PO_PDOI_INVALID_VENDOR when no row is found. It then validates the vendor site. When the vendor site type is anything other than 'RFQ SITE', the site is checked against po_supplier_po_sites_val_v; when the type equals 'RFQ SITE', validation against po_supplier_sites_val_v is used instead. A failure in either branch raises PO_PDOI_INVALID_VENDOR_SITE. Finally, when a vendor contact identifier is also supplied, the contact is validated against po_vendor_c. Both the vendor and the vendor site must be non-null before the site-level checks execute, and all three identifiers must be non-null before contact validation occurs.

• Second documented unit — The ETRM metadata records two documented procedures/functions total; only val_vendor_info is expanded in the available excerpt. The companion unit is internal to the same package body and supports the same supplier validation domain.

Tables Accessed

The package reads the following objects through APPS synonyms and validation views. No DML is performed; all access is read-only counting logic.

• PO_SUPPLIERS_VAL_V — Used to confirm that the supplied vendor identifier corresponds to a valid, currently selectable supplier.
• PO_SUPPLIER_PO_SITES_VAL_V — Used to confirm that a vendor site is valid for purchasing purposes when the site type is not 'RFQ SITE'.
• PO_SUPPLIER_SITES_VAL_V — Used to confirm that a vendor site is valid for RFQ purposes when the site type equals 'RFQ SITE'.
• PO_VENDOR_C — The supplier contact interface/validation table consulted when a vendor contact identifier must be verified.

Usage Notes

The ETRM metadata does not identify a concrete invoker, but the design of the API reveals its intended call paths. Because the function returns a BOOLEAN and an application-specific error code, it is suited to being called directly from PL/SQL in supplier entry forms, the supplier sites and contacts regions of the Vendor form, and from batch supplier import or conversion routines that need to validate vendor, site, and contact combinations before inserting or updating downstream records. Callers should treat the OUT error code as the contract for user-facing messages, expecting PO_PDOI_INVALID_VENDOR or PO_PDOI_INVALID_VENDOR_SITE as the failure indicators, and should be aware of the null-propagation rules: a null vendor ID short-circuits all further validation, and contact validation is skipped unless vendor, site, and contact are all present. The x_progress range codes (010 through 040) provide diagnostic breadcrumbs for debugging which checkpoint raised an error. Date-sensitive implementations should note the package header stamp (115.2, 2002), indicating this logic dates from an older Purchasing code line that remains in service across 12.1.1 and 12.2.2.