Search Results po_approval_list_lines




Overview
Explore in AI Chat

Overview

PO_APPROVAL_LIST_LINES is a Purchasing (PO) module table that stores the individual approver records belonging to a purchasing document approval list. Where the parent header table defines the approval list itself, this table defines each line-level approval element — the ordered approver, the person or role responsible for responding, the routing sequence, and the outcome of that approval action. In Oracle EBS 12.1.1 and 12.2.2 it is the transactional detail behind the approval hierarchy applied to purchase orders, purchase agreements, requisitions, and releases.

The table is owned by the PO schema and is documented as VALID in ETRM 12.2.2 with 36 columns. The metadata's heuristic Data Vault classification lists this object as standalone, meaning it does not itself act as a junction between two independent business entities. From a modeling perspective, it is more accurately treated as a satellite or dependent detail table whose business key is derived from its parent header; the mined classification simply reflects that no additional foreign keys beyond the header relationship were detected. Each row carries a full audit stamp (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) plus a fifteen-column ATTRIBUTE1–ATTRIBUTE15 descriptive flexfield block.

Key Information Stored

The surrogate primary key is APPROVAL_LIST_LINE_ID, enforced by PO_APPROVAL_LIST_LINES_PK and also backed by the unique index PO_APPROVAL_LIST_LINES_U1. The business-key candidate is the same column, indicating a single-column identifier rather than a composite natural key.

  • APPROVAL_LIST_HEADER_ID — foreign key to PO_APPROVAL_LIST_HEADERS; ties each line to its parent approval list.
  • APPROVAL_LIST_LINE_ID — surrogate primary key and unique business-key candidate for the line.
  • APPROVER_ID — the approver (typically an HR person or user reference) assigned to act on the document.
  • APPROVER_TYPE — classifies the approver, distinguishing employee, role, or other routing categories.
  • SEQUENCE_NUM — the ordering of the approver within the list; governs routing and parallel versus serial flow.
  • NEXT_ELEMENT_ID — pointer to the next element in the approval chain, defining the routing path.
  • RESPONDER_ID and FORWARD_TO_ID — the person who actually responded and any delegate to whom the action was forwarded.
  • STATUS — the current state of the line (for example pending, approved, rejected, or forwarded).
  • MANDATORY_FLAG and REQUIRES_REAPPROVAL_FLAG — control whether the approver must respond and whether a change forces re-approval.
  • RESPONSE_DATE, COMMENTS — the timestamp and notes recorded for the approval action.
  • NOTIFICATION_ID and NOTIFICATION_ROLE — the workflow notification and role used to alert the approver.

Common Use Cases and Queries

Reporting on approval routing and approval cycle time is the dominant use. A typical query joins the line to its header and to the document being approved, filters on status, and reports outstanding approvers:

  • Listing all active approvers for a given approval list: SELECT APPROVER_ID, SEQUENCE_NUM, STATUS FROM PO_APPROVAL_LIST_LINES WHERE APPROVAL_LIST_HEADER_ID = :header_id ORDER BY SEQUENCE_NUM;
  • Identifying stalled approvals by joining headers to document headers and filtering on STATUS and RESPONSE_DATE.
  • Auditing who actually approved a purchase order by comparing APPROVER_ID against RESPONDER_ID and RESPONSE_DATE.
  • Measuring approval cycle time using CREATION_DATE and RESPONSE_DATE per line.
  • Tracing delegated or forwarded approvals through FORWARD_TO_ID.

Because the table stores live routing state, it should be treated as transactional and queried with attention to the parent document's lifecycle.

Related Objects

  • PO_APPROVAL_LIST_HEADERS — parent table; join via APPROVAL_LIST_HEADER_ID.
  • PO_APPROVAL_LIST_HEADERS document association — links the list to the purchase order or agreement being approved.
  • PO_HEADERS_ALL and PO_LINES_ALL — the purchasing documents and lines subject to the approval list.
  • PO_REQUISITION_HEADERS_ALL — requisitions routed through the same approval framework.
  • PER_ALL_PEOPLE_F — resolves APPROVER_ID, RESPONDER_ID, and FORWARD_TO_ID to person records.
  • FND_USER — resolves approver identity to application users.
  • WF_NOTIFICATIONS — relates NOTIFICATION_ID to the workflow notification generated for each approver.