Search Results pol_attribute2

Overview

AP_PO_DETAILS_V is a Payables (AP) reporting view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It exposes a consolidated, denormalized projection of purchasing data spanning purchase order headers, purchase order lines, and purchase order distributions, making it convenient for Payables-related reporting, inquiry screens, and integration extracts. Rather than requiring the caller to join PO_HEADERS_ALL, PO_LINES_ALL, and PO_DISTRIBUTIONS_ALL explicitly, the view presents a single flattened result set in which the descriptive and descriptive flexfield (DFF) columns of each level are prefixed by their source object, allowing a Payables report to correlate a payment or invoice to its originating purchase order line and distribution.

The view is documented as VALID in the ETRM repository and is classified under the AP - Payables product, reflecting its primary consumption by Payables functionality rather than by the Purchasing module itself. The presence of the ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 columns from both the PO_HEADERS_ALL and PO_LINES_ALL sources explains why the search term "pol_attribute_category" resolves against this object: the view surfaces the line-level descriptive flexfield context as an explicit column, enabling attribute-driven reporting and reconciliation.

Underlying Base Objects

The documented base objects referenced by AP_PO_DETAILS_V are:

• PO_HEADERS_ALL (SYNONYM) — source of purchase order header attributes, identified in the view text by the POH alias.
• PO_LINES_ALL (SYNONYM) — source of purchase order line attributes, identified by the POL alias.
• PO_DISTRIBUTIONS_ALL (SYNONYM) — source of purchase order distribution attributes, referenced in the continuation of the view definition.

The view definition selects columns with POH, POL, and (per the referenced base objects) distribution-level prefixes, indicating an inner or outer join chain keyed on PO_HEADER_ID, PO_LINE_ID, and the corresponding distribution identifiers. The synonyms reside in APPS and resolve to the underlying PO schema tables. Because these are the same base tables used by the Purchasing module, the view reflects the authoritative transactional state of the document at query time; no materialization or aggregation is applied.

Key Columns

The view exposes a wide set of columns inherited directly from the base tables. Header-level columns include PO_HEADER_ID, TYPE_LOOKUP_CODE, SEGMENT1 through SEGMENT5 (the PO number and document segments), STATUS_LOOKUP_CODE, CURRENCY_CODE, and REFERENCE_NUM. The header DFF is represented by ATTRIBUTE_CATEGORY and ATTRIBUTE1–15, with GLOBAL_ATTRIBUTE_CATEGORY and GLOBAL_ATTRIBUTE1–20 provided for the global (typically audit or localization) flexfield.

Line-level columns include PO_LINE_ID, LINE_TYPE_ID, LINE_NUM, ITEM_DESCRIPTION, and a parallel set of descriptive flexfield columns: POL.ATTRIBUTE_CATEGORY (the "pol_attribute_category" context) plus POL.ATTRIBUTE1–15, and GLOBAL_ATTRIBUTE_CATEGORY with GLOBAL_ATTRIBUTE1–20. Distribution-level columns, drawn from PO_DISTRIBUTIONS_ALL, complete the projection with quantity, amount, and accounting distribution detail. The duplication of the ATTRIBUTE_CATEGORY name across header and line sources makes the source qualifier essential when referencing these columns in application code or ad hoc SQL.

Common Use Cases and Queries

Typical scenarios include Payables-to-Purchasing reconciliation, supplier spend analysis by PO DFF attributes, and extraction feeds requiring PO number, line description, currency, and DFF context in one row. A representative query selecting the line-level DFF context is shown below.

• SELECT po_header_id, segment1, line_num, item_description, attribute_category FROM ap_po_details_v WHERE attribute_category = :context;
• SELECT segment1 PO_NUMBER, line_num, currency_code, status_lookup_code FROM ap_po_details_v WHERE reference_num = :reference;
• SELECT po_header_id, segment1, attribute1 header_attr1, attribute_category FROM ap_po_details_v ORDER BY segment1, line_num;

Because duplicate column names exist across sources, queries joining this view to other objects should qualify columns explicitly. The view should be treated as a read-only reporting construct; data modification must always be performed against the underlying PO tables.