Search Results is_pcard_valid_and_active

Overview

APPS.PO_PCARD_PKG is a procurement-side validation package used by Oracle Purchasing to determine whether a supplier, supplier site, or purchasing document is eligible for payment by corporate procurement card (PCard). In Oracle E-Business Suite Release 12.1.1 and 12.2.2, the package serves as the runtime enforcement point for Purchasing's PCard rules, bridging purchasing transaction data with the payment card definitions held in Oracle Payables. The object is registered in the ETRM repository with status VALID in the APPS schema and is classified as an "OTHER" API rather than a formal public interface. It exposes no concurrent-program registration and is not referenced by any database object, indicating that it is called by Oracle Forms and internal purchasing logic rather than being a downstream dependency of other stored code. The package body is documented with six procedures and functions and depends on a compact set of Payables card tables and Purchasing session and collection types.

Key Procedures and Functions

Six documented entry points form the package interface. Each is designed either as a scalar predicate or as a bulk table-returning variant, reflecting the standard Oracle EBS pattern of pairing a single-row check with a set-based lookup for Forms block validation.

• IS_PCARD_VALID_AND_ACTIVE — Returns a Boolean-style result indicating whether a given procurement card is both valid and in active status. This is the fundamental gate used before a PCard can be associated with purchasing activity.
• GET_PCARD_VALID_ACTIVE_TBL — The table-returning counterpart to the validity check, used to retrieve the set of valid and active PCards for bulk processing or multi-row validation.
• IS_SITE_PCARD_ENABLED — Determines whether a specific supplier site is enabled for PCard usage. Supplier site enablement is a prerequisite for PCard purchasing, so this predicate is consulted when a site is selected on a document.
• GET_SITE_PCARD_ENABLED_TBL — The bulk form of site enablement validation, returning the collection of PCard-enabled sites.
• GET_VENDOR_PCARD_INFO — Retrieves PCard-related information for a vendor, aggregating card and supplier linkage data required by purchasing forms.
• GET_VALID_PCARD_ID — Returns the identifier of a valid procurement card, allowing callers to resolve a card reference to a concrete PCard ID for subsequent processing.

The pairing of "IS" predicates with "GET...TBL" functions reflects the internal structure of the package, which relies on PL/SQL table types PO_TBL_NUMBER and PO_TBL_VARCHAR1 for bulk results and PLITBLM for PL/SQL table manipulation.

Tables Accessed

The package reads payment card definitions and supplier linkage data from Oracle Payables through APPS synonyms:

• AP_CARDS and AP_CARDS_ALL — The base and multi-org views of payment card records; these supply card validity, active status, and card identifiers used by the validity and ID-resolution functions.
• AP_CARD_SUPPLIERS — Maps payment cards to suppliers and supplier sites, driving the site-enablement and vendor-information functions.
• PO_VENDOR_SITES_ALL — Provides supplier site context so that PCard enablement can be evaluated against the correct purchasing site.
• PO_SESSION_GT — A global temporary table used for session-scoped working data during validation.

In addition to these tables, the package depends on PO_CORE_S, PO_TBL_NUMBER, PO_TBL_VARCHAR1, PLITBLM, and the STANDARD package. No write operations are documented; the package is primarily a query and validation layer.

Usage Notes

Invocation is normally indirect. Oracle Purchasing forms and purchasing APIs call PO_PCARD_PKG when a user enters or defaults a procurement card on a purchasing document, when a supplier site is selected, and when the application must confirm that a card is valid and active before allowing the transaction to proceed. Because the package is documented as referenced by two other packages, customizations should generally call those higher-level APIs rather than PO_PCARD_PKG directly. Where direct use is required, custom code should wrap calls in exception handling, avoid reliance on undocumented private procedures, and recognize that the "OTHER" classification means Oracle does not guarantee interface stability across patches or upgrades. The package is not referenced by any database object, so changes to it do not cascade through the schema; nevertheless, its behavior directly affects PCard document validation and should be regression-tested after any Payables or Purchasing patch that touches AP_CARDS or AP_CARD_SUPPLIERS.