Search Results approval_reason

Overview

The PO_QUOTATION_APPROVALS_V view is a Purchasing (PO) module reporting object owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It presents a denormalized, query-ready representation of the approval records stored against supplier quotations, resolving raw foreign-key identifiers into human-readable values. Multiple ETRM sources describe this object with the terse description "Retrofitted," indicating that the view was introduced or re-pointed as part of the multi-org and TCA-era refactoring of the Purchasing schema, while its underlying table PO_QUOTATION_APPROVALS remains the transactional store.

The view serves as the principal read interface for quotation approval data in custom reports, concurrent programs, Oracle Discoverer/OBIA extracts, and OAF or Forms-based inquiries. It is especially relevant to users who search for the column approver_name: the view exposes APPROVER_ID together with the derived APPROVER_NAME, allowing applications to display the approving employee without joining HR tables themselves. Because approvals apply to a quotation line and shipment combination, the view also carries LINE_LOCATION_ID and the operating unit discriminator ORG_ID, making it suitable for multi-organization reporting under MOAC or the older operating unit (ORG_ID) security model.

Underlying Base Objects

The documented base objects referenced by the view are:

• PO_QUOTATION_APPROVALS (SYNONYM) — the transactional table holding one row per quotation approval, aliased PQA. The view selects the ROWID as ROW_ID and all functional and descriptive flexfield columns from this table.
• HR_EMPLOYEES (VIEW) — aliased HRE, joined on HRE.EMPLOYEE_ID = PQA.APPROVER_ID, providing the FULL_NAME exposed as APPROVER_NAME.
• PO_LOOKUP_CODES (VIEW) — joined twice (PLC, PLC1) to decode APPROVAL_TYPE against lookup type QUOTE APPROVAL TYPE and APPROVAL_REASON against lookup type QUOTE APPROVAL REASON, yielding the DISPLAYED_FIELD translations.
• FND_GLOBAL, FND_PROFILE, HR_GENERAL, HR_PERSON_NAME, HR_SECURITY — supporting packages referenced by the definition, typically for security and name-formatting context at runtime.

The joins are inner joins, so any approval row whose approver is not a valid HR employee, or whose type/reason code is not defined in PO_LOOKUP_CODES, is silently excluded from the view result set.

Key Columns

• ROW_ID — ROWID of the underlying approval row, used for uniqueness and for updatable-view behavior in Forms.
• QUOTATION_APPROVAL_ID — Primary key of the approval record.
• LINE_LOCATION_ID — Identifies the quotation line and shipment location against which the approval applies.
• APPROVER_ID / APPROVER_NAME — Employee identifier and resolved full name of the approver; APPROVER_NAME is the column most commonly targeted in ad-hoc queries.
• APPROVAL_TYPE / DISPLAYED_APPROVAL_TYPE — Raw lookup code and its user-facing description.
• APPROVAL_REASON / APPROVAL_REASON_CODE — Reason code and its displayed value.
• START_DATE_ACTIVE / END_DATE_ACTIVE — Effective dating window for the approval.
• COMMENTS, ORG_ID, plus REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, and PROGRAM_UPDATE_DATE — concurrency and audit columns for concurrent-program traceability.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield columns.

Common Use Cases and Queries

Typical uses include: listing all approvals for a quotation line, identifying who approved which quotation and when, auditing approvals by operating unit, and feeding quotation approval history into custom analytics.

SELECT APPROVER_NAME,
       DISPLAYED_APPROVAL_TYPE,
       APPROVAL_REASON_CODE,
       START_DATE_ACTIVE,
       END_DATE_ACTIVE
FROM   APPS.PO_QUOTATION_APPROVALS_V
WHERE  LINE_LOCATION_ID = :line_location_id
ORDER  BY START_DATE_ACTIVE;

SELECT APPROVER_NAME,
       COUNT(*) AS approval_count
FROM   APPS.PO_QUOTATION_APPROVALS_V
WHERE  ORG_ID = :org_id
GROUP  BY APPROVER_NAME
ORDER  BY 2 DESC;

Because the view is a join rather than a stored table, it is not directly updatable through DML; modifications must be performed against PO_QUOTATION_APPROVALS. Queries should filter on ORG_ID in multi-org environments and be aware of the inner-join behavior on HR and lookup data.