Search Results validate_vendor_purge




Overview
Explore in AI Chat

Overview

The APPS.PON_VENDOR_PURGE_GRP package is an Oracle E-Business Suite purchasing-family group API that governs the controlled removal of supplier records from the Oracle Purchasing and Oracle Sourcing data model. It belongs to the PON module — the Sourcing and Purchasing foundation — and is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking schema rather than the defining APPS schema. This matters because the package manipulates supplier-identifying rows that participate in sourcing events, and the invoking session must therefore already hold the appropriate purchasing and supplier-master privileges.

The package's purpose in EBS 12.1.1 and 12.2.2 is to provide a validated, two-stage deletion path for a vendor. It first determines whether a given vendor can safely be purged, and then performs the purge. This separation reflects the standard Oracle group-API design convention: a validation function that returns a status value without side effects, followed by an execution procedure that acts only on vendors that passed validation. The header comment records the original PL/SQL source revision 120.0 dated 2005/06/01, confirming the object has been carried forward largely unchanged into the 12.2 code line.

Key Procedures and Functions

The ETRM metadata documents exactly two entry points in this group:

  • VALIDATE_VENDOR_PURGE — a function that returns a VARCHAR2 status value. It accepts the standard API control parameters (API version, initialization of the message list, and the three standard return-status/ message-count/ message-data OUT parameters) together with the vendor identifier. Its purpose is to evaluate whether the specified vendor is eligible for purge, populating the message stack with any blocking conditions found.
  • VENDOR_PURGE — a procedure that performs the actual purge for the supplied vendor identifier. In addition to the standard API version and message-list parameters and the vendor identifier, it accepts a commit flag, allowing the caller to control transaction boundaries. Its standard OUT parameters report success, warning, or error through x_return_status, x_msg_count, and x_msg_data.

Both routines follow the uniform EBS API signature convention, which makes them safe to chain from concurrent programs and from custom PL/SQL that already manages FND_MSG_PUB message stacks.

Tables Accessed

The documented table references are PON_BIDDING_PARTIES and PON_BID_HEADERS, accessed through APPS synonyms. These are Oracle Sourcing objects: PON_BID_HEADERS stores the header of each sourcing negotiation (RFQ, auction, or bid), while PON_BIDDING_PARTIES records the suppliers invited to or participating in those negotiations. The relevance to vendor purge is direct: before a supplier can be removed, the package must establish whether that supplier is referenced as a bidding party on any sourcing event. Rows in PON_BIDDING_PARTIES tied to the vendor constitute a dependency that the validation function reports and that the purge procedure must handle. Because the header only lists these two tables, additional purchasing dependencies may be enforced indirectly through the validation logic and through other referenced objects rather than through direct DML in this unit.

Usage Notes

This package is a supplier-lifecycle utility. It is not a general-purpose deletion API and should not be treated as a substitute for the standard supplier purge concurrent program. Typical invocation patterns are:

  • Custom purge programs that call VALIDATE_VENDOR_PURGE first and invoke VENDOR_PURGE only when validation returns success, thereby avoiding partial or inconsistent cleanup.
  • Diagnostic scripts that use the validation function alone to determine why a supplier cannot be purged — for example, because the supplier remains an active bidding party on an open sourcing event.
  • Extension code layered over the Oracle Sourcing forms, where the group name convention (_GRP) signals a related set of APIs intended to be called together.

Callers must supply a valid API version, should pass FND_API.G_TRUE to initialize the message list on entry, and must inspect x_return_status against FND_API.G_RET_STS_SUCCESS before proceeding. Because the package executes under AUTHID CURRENT_USER, the invoking session, not APPS, must own the necessary object privileges. Only one dependent package is documented as referencing this group, indicating a narrow integration footprint.