Search Results party_id2




Overview
Explore in AI Chat

Overview

OKX_BUYERS_V is a reporting view owned by the APPS schema within the OKX – Contracts Integration product family in Oracle E-Business Suite 12.1.1 and 12.2.2. As its description ("Buyers") indicates, the view exposes a consolidated list of purchasing agents — the individuals recorded as buyers in Oracle Purchasing — enriched with human-resources attributes drawn from a people view. It functions as a lookup and integration source, typically consumed by contracts-integration logic and by concurrent programs or forms that need to present a buyer selection list. The view is documented as VALID in ETRM metadata. Because it joins Purchasing agent data to person data, it removes the need for downstream consumers to perform that join themselves, delivering a denormalized, presentation-ready record set.

Underlying Base Objects

The view text is defined over two documented base objects. The first is PO_AGENTS, exposed in the metadata as a synonym and the primary driver of the query, aliased as A. The second is OKX_PER_ALL_PEOPLE_V, a view (aliased PERV) that supplies person-level attributes such as full name, e-mail address, telephone number, and business group. The two are related through the join predicate PERV.PERSON_ID = A.AGENT_ID, meaning each buyer row is matched to exactly one person record by person identifier. Status and active-date logic is derived from PO_AGENTS.START_DATE_ACTIVE and END_DATE_ACTIVE. The metadata confirms that no other base tables are referenced, so lineage is limited to these two objects. In 12.1.1 and 12.2.2 the same definition is delivered with no functional divergence in the view text.

Key Columns

The view projects a mixture of real and placeholder columns. NAME carries the person's full name from the people view, while DESCRIPTION is constructed by concatenating EMAIL_ADDRESS and WORK_TELEPHONE. CATEGORY_ID originates from PO_AGENTS and identifies the buyer's purchasing category. BUSINESS_GROUP_ID, WORK_TELEPHONE, and EMAIL_ADDRESS are sourced from the people view. START_DATE_ACTIVE and END_DATE_ACTIVE expose the agent's effective period. STATUS is computed with nested DECODE/SIGN logic: it returns 'I' when the current date precedes the start date or exceeds the end date, and 'A' for active buyers. Several columns are deliberately NULL — SMALL_BUSINESS_FLAG, WOMEN_OWNED_FLAG, MINORITY_GROUP_LOOKUP, and PARTY_ID — while PARTY_ID2 and ID2 return the literal '#'. ID1 maps to AGENT_ID. These placeholders exist to satisfy a fixed interface contract, which is significant for consumers searching on party_id2.

Common Use Cases and Queries

The most frequent use is populating a buyer list of values for contract or sourcing forms, and reconciling buyers to persons for reporting. A caller searching for "party_id2" will find only the constant '#'; because the column is a stub, it cannot be used to join to HZ_PARTIES or other party-keyed tables. Joins must instead use ID1 (AGENT_ID) against PO_AGENTS.AGENT_ID or PER.PERSON_ID. A typical query is:

  • SELECT id1, name, email_address, status FROM okx_buyers_v WHERE status = 'A';
  • SELECT b.name, b.category_id, a.agent_id FROM okx_buyers_v b, po_agents a WHERE b.id1 = a.agent_id;
  • SELECT * FROM okx_buyers_v WHERE UPPER(name) LIKE UPPER(:search) ORDER BY name;

Consumers relying on PARTY_ID or PARTY_ID2 for integration to party-based tables should substitute the agent or person identifier, as those party columns are not populated in this view.