Results for “po_approval_list_lines_u1”

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

Overview

PO.PO_APPROVAL_LIST_LINES is a transactional table in the Oracle Purchasing (PO) schema that stores the individual lines comprising a requisition approval list. Each row represents one approver's slot within a specific approval list, capturing the routing order, the assigned approver, the workflow notification generated, and the responder's action. In Oracle EBS 12.1.1 and 12.2.2, requisition approval routing depends on this table: the Oracle Workflow approval process reads these lines to determine who must act, in what sequence, and whether reapproval is triggered after a change.

The table resides in the APPS_TS_TX_DATA tablespace and is classified as VALID in ETRM. Under a heuristic Data Vault classification, the table would best be modeled as a satellite attached to the approval list header hub represented by PO_APPROVAL_LIST_HEADERS. Because it carries descriptive, mutable attributes (status, comments, responder, notification) that change over the life of an approval cycle, it is not a pure business key hub on its own. This classification is a modeling suggestion only; the physical implementation remains a conventional Oracle EBS transactional table with standard WHO columns.

Key Information Stored

The single-column unique index PO_APPROVAL_LIST_LINES_U1 — the object name the user searched for — enforces uniqueness on APPROVAL_LIST_LINE_ID, which is also the primary key (PO_APPROVAL_LIST_LINES_PK). This is the surrogate identifier. No separate business-key column set is documented; the surrogate key is the only unique candidate.

• APPROVAL_LIST_LINE_ID — surrogate primary key for each approval list line.
• APPROVAL_LIST_HEADER_ID — foreign key to PO_APPROVAL_LIST_HEADERS, tying the line to its parent list.
• APPROVER_ID — the unique identifier of the assigned approver (typically an employee or user).
• SEQUENCE_NUM — the ordering of the line within the approval routing.
• NOTIFICATION_ID and NOTIFICATION_ROLE — the approval notification generated and the workflow role used.
• RESPONDER_ID and FORWARD_TO_ID — the person who responded and any forward-to target.
• STATUS — the approval action taken by the responder (e.g., approved, rejected, pending).
• MANDATORY_FLAG and REQUIRES_REAPPROVAL_FLAG — control flags indicating an obligatory approver and whether reapproval is needed.
• APPROVER_TYPE — classifies the approver (for example, position or user-based routing).
• COMMENTS — free-text comments associated with the line.
• RESPONSE_DATE and the WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) — audit and timing information.

Common Use Cases and Queries

Typical usage centres on approval history reporting, routing diagnostics, and bottleneck analysis. A frequent pattern joins the lines to their header to reconstruct the full approval chain for a requisition.

SELECT l.approval_list_line_id,
       l.approver_id,
       l.sequence_num,
       l.status,
       l.response_date
FROM   po.po_approval_list_lines l
WHERE  l.approval_list_header_id = :p_header_id
ORDER  BY l.sequence_num;

Because APPROVER_ID is indexed by PO_APPROVAL_LIST_LINES_N2, queries filtering by approver are efficient — useful for listing all approvals assigned to a given user or for measuring pending workload. The PO_APPROVAL_LIST_LINES_N1 index on APPROVAL_LIST_HEADER_ID supports the header-to-line drill-down. Reporting scenarios include approval cycle-time analysis (comparing notification creation to RESPONSE_DATE), rejected-step auditing via STATUS, and detecting approvals flagged for reapproval. Applications should treat these rows as Workflow-owned: direct DML is generally inadvisable, and reads should be filtered by the parent header for correctness.

Related Objects

The documented foreign key links this table to PO_APPROVAL_LIST_HEADERS through APPROVAL_LIST_HEADER_ID, which is the principal parent relationship. The following objects are commonly associated when working with approval routing in the PO schema:

• PO.PO_APPROVAL_LIST_HEADERS — parent table; join on APPROVAL_LIST_HEADER_ID.
• PO.PO_REQUISITION_HEADERS — the requisition whose approval list is being processed.
• PER.PER_ALL_PEOPLE_F / FND_USER — resolve APPROVER_ID and RESPONDER_ID to people and users.
• WF_NOTIFICATIONS — resolves NOTIFICATION_ID to the Workflow notification record.
• PO_REQUISITION_APPROVAL workflow — the Oracle Workflow process that reads and updates these lines.
• PO_APPROVAL_LIST_LINES_U1 — the unique index on APPROVAL_LIST_LINE_ID that enforces the primary key.

Joins to these objects provide the full context required for approval auditing and reporting.