Search Results paper_statement_req_flag

Overview

APBV_CARDS is a read-only reporting view owned by the APPS schema in Oracle E-Business Suite Payables (AP). It exposes corporate card and card member information maintained in the Payables credit card infrastructure, presenting a flattened, security-aware projection of the underlying card definition table. The view is registered as VALID in both ETRM 12.1.1 and 12.2.2 and is documented as a VIEW object within the AP - Payables product family. Its purpose is to provide a controlled read interface over corporate card records for reporting, inquiry screens, and integration extracts without requiring direct access to the base table.

The view carries two embedded constructs that are significant to its behavior. First, the literal '_DF:SQLAP:AP_CARDS:ACA' is emitted as the _DF column, which identifies the descriptive flexfield context associated with the AP_CARDS entity. Second, the WHERE predicate '_SEC:ACA.ORG_ID' IS NOT NULL is an Oracle Application Object Library row-level security token. At runtime this placeholder is substituted with a multi-org security clause, meaning the view returns only those card rows the querying responsibility is permitted to see for the given ORG_ID. Consequently, APBV_CARDS is inherently multi-org aware and should not be treated as an unfiltered data source.

Underlying Base Objects

The view is defined with a single source, the synonym AP_CARDS_ALL, aliased as ACA. AP_CARDS_ALL is the multi-organization variant of the corporate card table, storing one row per corporate card (and, where applicable, per card member) across operating units. Because APBV_CARDS filters through the ORG_ID security token rather than issuing a UNION of org-specific synonyms, it remains a thin, performant projection. The view is declared WITH READ ONLY, so no DML is permitted against it; inserts, updates, and deletes must target AP_CARDS_ALL directly. The documented relationship is therefore strictly one of projection: APBV_CARDS does not join to suppliers, employees, or lookup tables, and any enrichment beyond the card record itself must be performed by the caller.

Key Columns

• EMPLOYEE_ID — Identifier of the employee associated with the card.
• CARD_ID — Primary identifier of the corporate card record.
• CARDMEMBER_NAME — Name of the card member, stored directly on the card record rather than derived from HR.
• DEPARTMENT_NAME — Free-text department name captured for the card member; this is the column most relevant to departmental reporting and reconciliations.
• LIMIT_OVERRIDE_AMOUNT and TRX_LIMIT_OVERRIDE_AMOUNT — Card-level and transaction-level spending limit overrides.
• PROFILE_ID — Reference to the credit card profile defining default behavior.
• PHYSICAL_CARD_FLAG and PAPER_STATEMENT_REQ_FLAG — Flags indicating whether a physical card and paper statements were requested.
• LOCATION_ID — Location associated with the card holder.
• ORG_ID — Operating unit; the column driving the row-level security substitution.
• INACTIVE_DATE — Date on which the card record became inactive.
• CARD_EXPIRATION_DATE, CARD_PROGRAM_ID, CARD_REFERENCE_ID, REQUEST_ID — Card lifecycle and card program attributes.
• Audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY.

Common Use Cases and Queries

The view is typically queried to report active corporate cards by department, operating unit, or card program, and to drive card-member validation during expense or invoice entry. Because DEPARTMENT_NAME is stored as text on the card record, it is a reliable grouping attribute for departmental spend analysis without requiring joins to HR. A basic listing of active cards by department follows:

• SELECT cardmember_name, department_name, card_expiration_date FROM apbv_cards WHERE inactive_date IS NULL ORDER BY department_name;
• SELECT org_id, department_name, COUNT(*) FROM apbv_cards WHERE inactive_date IS NULL GROUP BY org_id, department_name;
• SELECT card_id, cardmember_name, limit_override_amount, trx_limit_override_amount FROM apbv_cards WHERE department_name = :dept;

When extending these queries, note that ORG_ID filtering is applied automatically by the security token, and that the _DF column signals the AP_CARDS flexfield context should the caller need to resolve descriptive flexfield segments separately.