Results for “acceptance_status”

6 results




Overview
Explore in AI Chat

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The APPS.POS_ACK_SELECT_V view is one of the core selection views used by Oracle iProcurement (product code ICX) in Oracle E-Business Suite 12.1.1 and 12.2.2. Its purpose is to present a unified list of purchase order documents for which supplier acknowledgement — that is, acceptance, rejection, or a pending acceptance decision — is relevant. The name of the view, together with its underlying dependence on PO_ACCEPTANCES and the PO_HEADERS acceptance columns (ACCEPTANCE_REQUIRED_FLAG, ACCEPTANCE_DUE_DATE), makes it the primary data source behind iProcurement and Procurement acceptance-related pages and related concurrent processes. Users who search for the term "po_acceptances" are typically investigating how acceptance records are surfaced, and this view is the most common read-only entry point. It consolidates both blanket/standard purchase order headers and their individual releases into a single, denormalised result set, applying the business rule that only approved, open, and uncancelled documents (APPROVED_FLAG = 'Y', CLOSED_CODE open or null, CANCEL_FLAG not 'Y') are eligible for acknowledgement. The view is a read-only object and is owned by the APPS schema with a VALID status.

Underlying Base Objects

The documented base objects reflect both the driving tables and the supporting lookups used to enrich the acceptance rows. PO_HEADERS and PO_RELEASES form the two branches of the view, combined with a UNION ALL. PO_ACCEPTANCES is joined to both branches with the outer join operator (+) on PO_HEADER_ID and REVISION_NUM, so a header or release with no acceptance record is still returned, with its accepted flag defaulted to 'NONE'. Supporting descriptive attributes are drawn from PO_VENDORS and PO_VENDOR_SITES (supplier and site names), HR_LOCATIONS (ship-to location), ORG_FREIGHT (ship-via and freight descriptions), and HR_EMPLOYEES (buyer/agent records). The PO_INQ_SV package supplies the buyer name through GET_PERSON_NAME. Security and context are handled through FND_GLOBAL and FND_PROFILE, and HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY provide the person-name and security-profile resolution used by the iProcurement search framework.

Key Columns

  • ACCEPTED_FLAG / derived accepted status — Taken from PO_ACCEPTANCES, or defaulted to 'NONE' via NVL when no acceptance row exists.
  • ACCEPTANCE_LOOKUP_CODE — The lookup code describing the acknowledgment type.
  • PO_HEADER_ID / PO_RELEASE_ID — Identifiers for the document; the release branch concatenates header SEGMENT1 and RELEASE_NUM into a display document number.
  • REVISION_NUM — Revision of the header or release, used to align the correct acceptance row.
  • ACCEPTANCE_REQUIRED_FLAG — Decoded to 'YES'/'NO' to indicate whether acknowledgement is mandatory.
  • ACCEPTANCE_DUE_DATE — The date by which acknowledgement is expected.
  • APPROVED_FLAG — Defaulted to 'N' where null; the view filters on approved documents.
  • VENDOR_NAME / VENDOR_SITE_CODE — Supplier identity and site from PO_VENDORS and PO_VENDOR_SITES.
  • Buyer/agent columns — AGENT_ID and the resolved person name from PO_INQ_SV.GET_PERSON_NAME.

Common Use Cases and Queries

Typical scenarios include building acceptance worklists, reporting outstanding acknowledgements, and troubleshooting why a document does or does not appear in iProcurement. A representative query is:

  • SELECT po_header_id, segment1, vendor_name, accepted_flag, acceptance_due_date FROM apps.pos_ack_select_v WHERE NVL(accepted_flag,'NONE') = 'NONE' ORDER BY acceptance_due_date;
  • SELECT segment1, po_release_id, vendor_name, accepted_flag FROM apps.pos_ack_select_v WHERE accepted_flag = 'Y';
  • SELECT vendor_name, COUNT(*) FROM apps.pos_ack_select_v WHERE acceptance_required_flag = 'YES' GROUP BY vendor_name;

Because the view already restricts output to approved, open, non-cancelled documents and resolves supplier, buyer, and location descriptions, it is well suited to ad-hoc reporting in Oracle Discoverer, BI Publisher, or direct SQL, avoiding the need to reconstruct the join logic against PO_HEADERS, PO_RELEASES, and PO_ACCEPTANCES manually.