Search Results non_bid_list_bidders

Overview

PON_AUCTION_PKG is a core PL/SQL package in the APPS schema that supports the Oracle Sourcing (Oracle iProcurement/Sourcing) auction and negotiation functionality within Oracle E-Business Suite 12.1.1 and 12.2.2. It provides the procedural foundation for managing the full auction lifecycle — from bidder registration and auction start through bidding, bid retraction, disqualification, and award. The package status is documented as VALID in ETRM, indicating that it is a compiled and active database object in the APPS schema.

The package is heavily integrated into the sourcing module. It is referenced by twenty-six other packages, including PON_AUCTION_APPROVAL_PKG, PON_AUCTION_CREATE_PO_PKG, PON_AUCTION_INTERFACE_PKG, PON_AWARD_PKG, PON_RESPONSE_PVT, and PON_NEGOTIATION_PUBLISH_PVT. This dependency footprint confirms that PON_AUCTION_PKG acts as a central utility layer for auction-related processing rather than an isolated component. Its API classification is reported as OTHER, and 150 procedures and functions are documented, of which a representative subset is described below.

Key Procedures and Functions

The documented procedures cover auction state transitions, bidder management, and notification logic:

• START_AUCTION — Marks the transition of an auction into an active state, typically enabling bidding activity.
• START_BID — Initiates the bid entry process for a registered bidder.
• RETRACT_BID — Allows a bidder to withdraw a previously submitted bid, subject to auction rules.
• DISQUALIFY_BID — Removes a submitted bid from consideration, typically used to enforce compliance with auction terms.
• AWARD_BID — Designates a winning bid, feeding downstream award and purchase order creation processes.
• REGISTERED_BIDDER / UNREGISTERED_BIDDERS / BIDDERS_LIST / DOES_BIDDER_LIST_EXIT / NON_BID_LIST_BIDDERS / CHECK_AUCTION_BIDDER — Collective routines for registering bidders and reporting on registered, unregistered, and non-bid list participants.
• CREATE_LOCAL_ROLES / POPULATE_ROLE_WITH_INVITEES — Establish local role definitions and populate them with auction invitees for access control and collaboration.
• REACHED_AUCTION_START_DATE / REACHED_AUCTION_END_DATE — Date-based checks used to determine whether an auction has reached its scheduled start or end.
• NOTIFY_BIDDER_LIST_START / NOTIFY_BIDDER_LIST_CANCEL / NOTIFY_NON_BIDDER_LIST_CANCEL / NOTIFY_BIDDER_LIST_END / NOTIFY_NON_BIDDER_LIST_END — Generate notifications to bidder and non-bidder populations at auction start, cancellation, and close.

Tables Accessed

The package reads and writes to several core Sourcing and Oracle foundation tables via APPS synonyms:

• PON_AUCTION_HEADERS_ALL — Primary auction header record, holding auction definition, status, and scheduling data.
• PON_AUC_DOCTYPES — Auction document type setup, governing auction classification.
• PON_ACCEPTANCES, PON_ACTION_HISTORY, PON_AUCTION_EVENTS — Track bidder acceptance, audit history of actions, and auction event sequencing.
• FND_DOCUMENT_CATEGORIES / FND_LOOKUPS / FND_LOOKUP_VALUES — Supply category and lookup validation values.
• FND_USER, FND_REGISTRATIONS, FND_APPLICATION — Resolve user identity and registration context.
• FND_LANGUAGES, FND_TERRITORIES, FND_TIMEZONES_B, FND_TIMEZONES_TL — Provide localization, territory, and timezone handling for scheduling and notifications.
• HZ_PARTIES — Supplier/party master data for bidder identification.

Usage Notes

PON_AUCTION_PKG is not typically called directly by end users; it is invoked programmatically by other Sourcing packages, Oracle Sourcing forms, workflow components such as PON_WF_UTL_PKG, and concurrent programs that process auctions, bids, and notifications. Because it is referenced by PON_AUCTION_INTERFACE_PKG and PON_AUCTION_CREATE_PO_PKG, it participates in both interface/import processing and award-to-purchase-order flows. Custom extensions should invoke this package only through its documented procedure signatures, since it is an internal implementation package rather than a formally published public API. Any modifications to underlying tables should follow Oracle's standards for the APPS schema.