Search Results release_number




Overview
Explore in AI Chat

Overview

POS_ACK_SELECT is a table owned by the ICX schema in Oracle EBS 12.1.1 and 12.2.2, operating within the Oracle iProcurement module. It serves as a transient staging and selection structure used to capture buyer or requisitioner acknowledgement actions against purchase orders and purchase order releases during the iProcurement acknowledgement workflow. The table holds the working set of documents presented to a user for acceptance or rejection, together with the acceptance metadata collected during that interaction. It carries 31 documented columns and one foreign key relationship to PO_RELEASES_ALL through PO_RELEASE_ID.

Under the heuristic Data Vault classification supplied in the ETRM metadata, POS_ACK_SELECT is best modeled as a standalone structure — neither a classic hub, link, nor satellite. This classification reflects its role as a session-oriented work table rather than a persistent master or transactional entity. Rows are populated when a user queries documents requiring acknowledgement and are largely disposable after the acknowledgement transaction is committed.

Key Information Stored

The table blends surrogate identifiers, business document keys, and acknowledgement-specific attributes. The most significant columns are:

Common Use Cases and Queries

Typical usage centers on the iProcurement acknowledgement page and supporting reports. A buyer reviewing pending acknowledgements might run:

  • SELECT PO_NUMBER, RELEASE_NUMBER, SUPPLIER_NAME, TOTAL, ACCEPTANCE_STATUS FROM ICX.POS_ACK_SELECT WHERE ACCEPTANCE_REQUIRED = 'Y'; to list documents still requiring action.
  • Aggregation of accept versus reject counts for a supplier: SELECT SUPPLIER_NAME, COUNT(*) FROM ICX.POS_ACK_SELECT WHERE ACCEPT = 'Y' GROUP BY SUPPLIER_NAME;
  • Joining to PO_RELEASES_ALL on PO_RELEASE_ID to enrich with authoritative release data, and to PO_HEADERS_ALL on PO_HEADER_ID for header context.
  • Performance or cleanup reporting to detect stale selection rows, since the table is intended to be ephemeral.

Because rows originate from an interactive session, queries should generally be scoped by buyer, supplier, or document number rather than treated as a historical archive.

Related Objects

  • PO_RELEASES_ALL — joined via POS_ACK_SELECT.PO_RELEASE_ID; the documented foreign key target supplying release-level header data.
  • PO_HEADERS_ALL — joined via PO_HEADER_ID for purchase order header attributes.
  • PO_LINES_ALL / PO_LINE_LOCATIONS_ALL — dependents used to resolve line and shipment detail behind an acknowledgement.
  • PO_VENDORS / PO_VENDOR_SITES_ALL — resolve supplier and supplier-site identifiers.
  • HR_LOCATIONS_ALL — resolves SHIPTO_LOCATION_ID.
  • PER_PEOPLE_F / PER_ALL_PEOPLE_F — resolves BUYER_ID to a person name.
  • ICX.POS_ACK_SELECT is consumed by iProcurement acknowledgement BC4J/ADF pages and related ICX APIs rather than referenced by persistent child tables, consistent with its standalone classification.