Search Results pos_viewpo_summary_v

Overview

POS_VIEWPO_SUMMARY_V is a reporting view within the Oracle E-Business Suite iSupplier Portal (POS) module. It consolidates purchase order header information together with the latest acceptance record associated with each approved purchasing document, presenting a unified, denormalized result set intended primarily for display and enquiry within the iSupplier Portal rather than for transactional processing. The view is a summary construct: it exposes one row per approved purchase order (or blanket, contract, or planned order), enriched with acceptance-related attributes such as the accepted flag, acceptance due date, and the action date of the most recent acceptance entry.

Because the view flattens data drawn from headers, acceptance history, and organization definitions, it is well suited to reporting scenarios where the caller requires the current acceptance state of a purchasing document without performing join and aggregation logic themselves. It is read-only and does not participate in any DML path.

Underlying Base Objects

The view is defined over three primary objects. PO_HEADERS_ALL supplies the purchasing document header, including approval, revision, type, currency, vendor, and descriptive attributes. PO_ACCEPTANCES holds the acceptance line responsible for tracking required acknowledgements, accepted flags, action dates, and the revision against which acceptance was recorded. HR_ALL_ORGANIZATION_UNITS_TL provides the operating unit name translated according to the session language.

The join between headers and acceptances is an outer join, deliberately tolerant of orders that have not yet been accepted. Two additional constraints narrow the acceptance side: only records where PO_RELEASE_ID is null are considered, and the header-to-acceptance match is further restricted to the single most recent acceptance row per header, determined by a correlated subquery returning MAX(CREATION_DATE) from PO_ACCEPTANCES. Where no acceptance exists, the acceptance columns resolve to null. Header rows are qualified by approved flag, authorization status, and a fixed set of document types.

Key Columns

• PO_RELEASE_FLAG — literal 'PO', distinguishing these rows from release records in related views.
• PO_NUM / SEGMENT1 / PO_HEADER_ID — document number and primary key of the header.
• TYPE_NAME / TYPE_LOOKUP_CODE — decoded document type (Blanket, Contract, Standard, Planned) derived via FND_MESSAGE_CACHE lookups.
• ACCEPTANCE_FLAG — the ACCEPTED_FLAG from the latest acceptance record, indicating acceptance state.
• ACCEPTANCE_DUE_DATE / APPROVED_DATE / ACTION_DATE — header acceptance due date, approval date, and the action date of the matched acceptance entry.
• ACCEPTANCE_REQUIRED_FLAG — whether the document requires supplier acceptance.
• VENDOR_ID, VENDOR_SITE_ID, VENDOR_CONTACT_ID, AGENT_ID — supplier, site, contact, and buyer references.
• CURRENCY_CODE, COMMENTS, SHIP_VIA_LOOKUP_CODE, SHIP_TO_LOCATION_ID — descriptive and shipping attributes.
• CANCEL_FLAG, CLOSED_CODE, FROZEN_FLAG — status flags with normalization applied (cancel flag suppressed for internal, closed defaults to 'OPEN', frozen defaults to 'N').
• ORG_ID / ORG_NAME — operating unit identifier and translated name.
• ATTRIBUTE1 through ATTRIBUTE15, ATTRIBUTE_CATEGORY — descriptive flexfield context and segments.

Common Use Cases and Queries

A frequent requirement — and the one associated with the search term po_acceptances — is identifying approved purchase orders and their current acceptance status. For example, listing all approved standard orders with outstanding acceptance:

SELECT po_num, type_name, vendor_id, acceptance_flag,
       acceptance_due_date, action_date, org_name
FROM   pos_viewpo_summary_v
WHERE  acceptance_required_flag = 'Y'
AND    NVL(acceptance_flag,'N') = 'N'
ORDER BY acceptance_due_date;

Another common pattern filters by document type or operating unit, typically driving supplier-facing portal dashboards:

SELECT po_num, approved_date, closed_code, frozen_flag
FROM   pos_viewpo_summary_v
WHERE  type_lookup_code = 'STANDARD'
AND    org_id = :p_org_id
AND    closed_code = 'OPEN';

Because the view already resolves the latest acceptance revision and decodes the type, it removes the need to replicate the MAX(CREATION_DATE) subquery and FND message lookups in every report. It is appropriate for enquiry, extract, and portal display purposes, but should not be relied upon for low-level acceptance history analysis, since only the most recent acceptance per header is projected.