Results for “po_agents_name_v”

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

Overview

The APPS.PO_AGENTS_NAME_V view is a Purchasing (PO) module database object that exposes a consolidated listing of active buyers (agents), their full person names, and a real-time count of their currently open purchase orders. It resides in the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2 and is documented in ETRM as "10SC ONLY," indicating that its functional scope is limited to a specific localization or vertical deployment rather than the general Purchasing product set. Because it joins human-resources person data to purchasing agent records, it acts as a bridge between the HR and Purchasing domains, presenting a security-filtered view of buyers suitable for operational reporting, workload monitoring, and integrations that require a buyer identifier mapped to a display name.

The view reflects the control rules enforced elsewhere in EBS: it restricts output to agents who are current, valid employees in the effective-dated person table, honors HR security profiles and business-group separation, and respects the agent record's own active date range. This makes it a defensible source for reporting on buyer activity without exposing records that the querying user is not privileged to see.

Underlying Base Objects

The view text joins PO_AGENTS (synonym resolving to the purchasing agents table) with PER_ALL_PEOPLE_F (synonym over the effective-dated HR person/assignment table), matched on POA.AGENT_ID = PAPF.PERSON_ID. Three supporting objects are referenced at runtime: the HR_SECURITY and HR_GENERAL packages, and the PO_BUYER_WORKLOAD_SV package. HR_SECURITY supplies the VIEW_ALL profile and the SHOW_RECORD function that enforces per-record row-level security, while HR_GENERAL supplies the business-group resolution functions (GET_XBG_PROFILE, GET_BUSINESS_GROUP_ID) used to constrain the result set to the session's business group. PO_BUYER_WORKLOAD_SV provides the scalar function NUM_OPEN_PO, which the view invokes row by row to compute open purchase order counts for each agent.

Because the workload count is a packaged function call rather than a join, the view performs a function execution per row, which affects performance characteristics on large agent populations.

Key Columns

• BUYER_ID — The agent identifier, aliased from POA.AGENT_ID. This is the join key to purchasing documents and the value used as the argument passed to PO_BUYER_WORKLOAD_SV.NUM_OPEN_PO.
• FULL_NAME — The agent's complete name from PER_ALL_PEOPLE_F.FULL_NAME, suitable for display, list-of-values presentation, and reporting labels.
• NUM_OPEN_PO — The count of open purchase orders for the agent, returned by the workload server package. This is the primary metric the view is designed to surface.

Common Use Cases and Queries

Typical uses include buyer workload dashboards, assignment validation, and reporting that must display a buyer's name alongside a buyer identifier. A basic query listing all visible buyers and their open-order counts is:

• SELECT buyer_id, full_name, num_open_po FROM apps.po_agents_name_v ORDER BY num_open_po DESC;
• SELECT full_name FROM apps.po_agents_name_v WHERE buyer_id = :buyer_id; — name lookup for a known agent.
• SELECT buyer_id, full_name FROM apps.po_agents_name_v WHERE num_open_po = 0; — identify buyers with no open workload.
• SELECT COUNT(*) FROM apps.po_agents_name_v; — count active, security-visible buyers.

Because results are filtered by HR_SECURITY, two users may receive different row sets for the same query, and because agent and employee effective dates are applied, historical buyers no longer active will not appear. Queries joining this view back to PO_HEADERS_ALL should use BUYER_ID as the correlation key.