Search Results paycard_reference_id

Overview

AP_CARDS_V is a Payables (AP) dictionary view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It presents a denormalized, reporting-oriented projection of corporate payment card data, combining attributes from the corporate card record itself with the associated card profile, card program, and the person to whom the card is issued. The object carries a status of VALID and is classified in ETRM metadata as "Retrofitted," indicating that the view was introduced or rebuilt to preserve backward compatibility with an earlier interface while the underlying schema evolved.

The view is commonly used by report developers and integrators who need a single, join-free source for cardholder, program, and profile attributes. Rather than querying AP_CARDS, AP_CARD_PROFILES, AP_CARD_PROGRAMS, and PER_PEOPLE_X separately, a developer consumes AP_CARDS_V and retrieves card numbers, employee identifiers, program names, and profile names in one row. Because the view exposes both CARD_REFERENCE_ID and PAYCARD_REFERENCE_ID—the latter being the column most frequently sought when users search for "paycard_reference_id"—it serves as the primary access point for paycard reference resolution in custom queries, extracts, and interfaces.

Underlying Base Objects

ETRM documentation for 12.2.2 lists the referenced base objects as AP_CARDS (SYNONYM), AP_CARD_PROFILES (SYNONYM), AP_CARD_PROGRAMS (SYNONYM), PER_PEOPLE_X (VIEW), and the packages HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY. The view definition joins AP_CARDS (alias AC) as the driving table to AP_CARD_PROFILES (alias ACP) and AP_CARD_PROGRAMS (alias ACPR), with outer joins preserved for the profile and person lookups.

The join predicates are AC.PROFILE_ID = ACP.PROFILE_ID(+), ACPR.CARD_PROGRAM_ID = AC.CARD_PROGRAM_ID, and AC.EMPLOYEE_ID = P.PERSON_ID(+). Participation of the HR packages reflects the use of person-name and security logic behind PER_PEOPLE_X, which supplies FULL_NAME, EMPLOYEE_NUMBER, NATIONAL_IDENTIFIER, and DATE_OF_BIRTH. In practice, the outer joins mean that every card row in AP_CARDS is returned even where a matching profile or person record is absent, although a program match is effectively required.

Key Columns

The view exposes the full column set of AP_CARDS, including CARD_ID, CARD_NUMBER, EMPLOYEE_ID, PROFILE_ID, CARD_PROGRAM_ID, ORG_ID, and the descriptive flexfield columns ATTRIBUTE1 through ATTRIBUTE30 along with ATTRIBUTE_CATEGORY.

• ROW_ID — row identifier of the underlying AP_CARDS row, used for updates through the view.
• CARD_REFERENCE_ID — reference identifier associated with the card record.
• PAYCARD_REFERENCE_ID — the paycard-specific reference identifier, the column targeted by the user's search term.
• FULL_NAME, EMPLOYEE_NUMBER, NATIONAL_IDENTIFIER, BIRTHDATE — sourced from PER_PEOPLE_X for the cardholder.
• PROFILE_NAME — from AP_CARD_PROFILES; CARD_PROGRAM_NAME — from AP_CARD_PROGRAMS.
• CARD_EXPIRATION_DATE, INACTIVE_DATE, LIMIT_OVERRIDE_AMOUNT, TRX_LIMIT_OVERRIDE_AMOUNT — card status and limit overrides.
• PHYSICAL_CARD_FLAG, PAPER_STATEMENT_REQ_FLAG, LOCATION_ID, DEPARTMENT_NAME, CARDMEMBER_NAME — operational and mailing attributes.

Common Use Cases and Queries

The most frequent requirement is resolving the paycard reference identifier for a given card or employee, typically for reconciliation against a bank or paycard processor extract.

SELECT CARD_ID, CARD_NUMBER, EMPLOYEE_ID, PAYCARD_REFERENCE_ID
FROM   APPS.AP_CARDS_V
WHERE  PAYCARD_REFERENCE_ID = :p_reference_id;

A second common pattern joins the view to expense or payment data to report cardholder and program context alongside transactions, filtering by ORG_ID for multi-org security. A third pattern extracts active cards for a program, using CARD_PROGRAM_NAME, INACTIVE_DATE, and the limit override columns. Because ROW_ID is exposed, the view can also be used in controlled maintenance screens, though inserts are not supported through the join.

Consumers should account for the outer joins and the HR security logic behind PER_PEOPLE_X, which may restrict visible person rows depending on the querying responsibility. Querying as APPS or a role with unrestricted HR security avoids unexpected omission of cardholder names.