Search Results plc_auth




Overview
Explore in AI Chat

Overview

APPS.POR_VIEW_HEADER_V is a reporting view in the Oracle E-Business Suite Purchasing module that consolidates requisition header information for display and integration purposes. It presents a flattened, user-facing representation of the purchase requisition header, joining primary requisition data with preparer name, authorization status description, procurement card details, currency formatting, and system parameters. The view is designed primarily for inquiry screens, OAF-based or forms-based requisition search pages, and for downstream reporting or integration where a single row per requisition header is required without the burden of multi-table joins at the consumer level.

Because it exposes derived values through PL/SQL functions and profile-based formatting rather than raw foreign keys alone, it is particularly suited to read-only scenarios such as operational dashboards, approval worklists, and interface extracts. The view does not store data; it is a query-time union of header facts resolved against supporting lookup and personnel data.

Underlying Base Objects

The view is defined over several referenced base objects, each contributing a distinct facet of the requisition header:

  • PO_REQUISITION_HEADERS (synonym) — the primary source providing requisition_header_id, segment1 (requisition number), preparer_id, description, note_to_authorizer, authorization_status, pcard_id, emergency_po_num, and attribute1 through attribute15.
  • PER_ALL_PEOPLE_F (synonym) — supplies the preparer's full_name, joined on person_id and constrained by sysdate between effective_start_date and effective_end_date.
  • PO_LOOKUP_CODES (view) — aliased as plc_auth, provides the displayed_field for the AUTHORIZATION STATUS lookup_type, joined on lookup_code equal to NVL(authorization_status, 'INCOMPLETE'). This is the source of the user search term "plc_auth."
  • AP_CARDS (synonym) — outer-joined (apc.card_id (+)) to requisition pcard_id, supplying card_number and description.
  • GL_SETS_OF_BOOKS (view) and FINANCIALS_SYSTEM_PARAMETERS (synonym) — provide the set of books and functional currency used for amount formatting.
  • POR_VIEW_REQS_PKG (package) — supplies derived values such as urgent flag, note to agent, requester, deliver-to, and requisition total.
  • FND_CURRENCY, FND_GLOBAL, FND_PROFILE (packages) — used for currency safe format mask and date format profile (ICX_DATE_FORMAT_MASK).

Key Columns

  • requisition_header_id and segment1 — primary identifier and the user-visible requisition number.
  • preparer_id / full_name — the individual who created the requisition.
  • authorization_status / displayed_field (plc_auth) — code and translated status text from PO_LOOKUP_CODES.
  • pcard_id / card_number / description — procurement card linkage where applicable.
  • note_to_authorizer / note_to_agent — approval-related free text and package-derived agent notes.
  • urgent_flag, req_total, requester, deliver_to — computed via POR_VIEW_REQS_PKG.
  • creation_date (formatted) and formatted requisition total — profile- and currency-aware display strings.
  • emergency_po_num and attribute1–attribute15 — descriptive flexfield content.

Common Use Cases and Queries

Typical uses include approval worklists, requisition inquiry pages, and extract feeds requiring status display text. A representative query filtering by authorization status:

SELECT h.segment1, h.full_name, h.displayed_field,
       h.authorization_status, h.req_total_formatted
FROM   apps.por_view_header_v h
WHERE  h.displayed_field IS NOT NULL
  AND  h.creation_date >= :from_date;

Users searching for "plc_auth" are typically tracing the authorization status lookup join. Confirming status codes:

SELECT h.segment1, h.authorization_status, plc.displayed_field
FROM   apps.por_view_header_v h, apps.po_lookup_codes plc
WHERE  plc.lookup_type = 'AUTHORIZATION STATUS'
  AND  plc.lookup_code = NVL(h.authorization_status,'INCOMPLETE');

Because the view relies on function calls and current-date personnel joins, consumers should expect moderate cost and should avoid row-by-row invocation in high-volume batch processes.