Search Results update_header_history

Overview

APPS.AP_IAW_PKG is the core PL/SQL package that implements Invoice Approval Workflow (IAW) processing within Oracle Payables. IAW is the framework that routes invoices through a configurable approval hierarchy before they can be paid, and this package encapsulates the business logic that drives that routing, evaluates approval requirements, records approver decisions, and maintains the approval audit trail. The package is classified as an "OTHER" API, meaning it is internal infrastructure rather than a formally published open interface, and it operates within the APPS schema against a set of Payables approval tables.

Functionally, AP_IAW_PKG sits between the Invoice Approval Workflow engine and the underlying Payables data model. It determines whether a given invoice header or line requires approval, identifies the appropriate approver (or list of approvers), dispatches and responds to workflow notifications, raises workflow events, and persists approval and rejection history. Because invoice approval is a mandatory control in most Payables implementations, this package participates directly in the invoice validation lifecycle and in the audit trail that supports segregation-of-duties and compliance requirements.

Key Procedures and Functions

The package exposes 53 documented procedures and functions. The most significant are grouped below by purpose.

• Requirement evaluation: CHECK_HEADER_REQUIREMENTS and CHECK_LINE_REQUIREMENTS determine whether a given invoice header or invoice line falls within the criteria that mandate approval, based on the configured IAW rules.
• Approver resolution: IDENTIFY_APPROVER, GET_APPROVERS, and GET_ALL_APPROVERS resolve the list of approvers applicable to an invoice or line. SET_APPROVER records the selected approver against the approval history records.
• Workflow interaction: NOTIFICATION_HANDLER and RESPONSE_HANDLER process workflow notifications and the approver's response (approve, reject, reassign). IAW_RAISE_EVENT raises the workflow event that advances the approval process.
• Escalation and termination: ESCALATE_HEADER_REQUEST and ESCALATE_LINE_REQUEST handle time-based escalation when an approver does not respond. TERMINATE_APPROVAL and STOP_APPROVAL end an in-progress approval, for example when an invoice is cancelled or a hold is applied.
• History maintenance: INSERT_HEADER_HISTORY, INSERT_LINE_HISTORY, UPDATE_HEADER_HISTORY, and UPDATE_LINE_HISTORY write and maintain the approval audit trail. CLEAR_AME_HISTORY_HEADER and CLEAR_AME_HISTORY_LINE remove AME-related approval history entries.
• Attribute handling: SET_ATTRIBUTE_VALUES populates the approval attribute values used by the AME (Approvals Management Engine) integration.

Tables Accessed

Via APPS synonyms, the package reads and writes the following tables.

• Approval history: AP_INV_APRVL_HIST_ALL and AP_INV_APRVL_HIST_S for header-level approval history, and AP_LINE_APRVL_HIST_ALL and AP_LINE_APRVL_HIST for line-level history. These are the primary audit tables written by INSERT/UPDATE_*_HISTORY.
• Approver data: AP_APINV_APPROVERS and the global temporary table AP_APPROVERS_LIST_GT support approver resolution and caching during a workflow run.
• Invoice data: AP_INVOICES, AP_INVOICES_ALL, AP_INVOICE_LINES, AP_INVOICE_LINES_ALL, and AP_INVOICE_DISTRIBUTIONS_ALL supply the invoice attributes evaluated by the requirement checks.
• Holds: AP_HOLDS_ALL and AP_HOLD_CODES are consulted because holds can block or route approval.
• Supporting reference data: FND_USER for approver identity, and PA_EXP_ORGS_IT for project expenditure organization hierarchy lookups used in approver resolution.

Usage Notes

AP_IAW_PKG is invoked indirectly rather than directly by end users. It is driven by the Invoice Approval Workflow, Oracle Workflow's notification and event infrastructure, and the AME engine during invoice validation and approval cycles. It is also triggered from concurrent processing and from the invoice entry forms when an invoice is submitted, cancelled, or subjected to a hold change.

Because the package is documented as an internal package with zero dependent packages, customers and integrators should not call its procedures directly in custom code. Extensions to approval behavior are implemented through supported AME rule configuration and approved workflow customization, not by wrapping these procedures. Any direct modification risks corrupting the approval history tables, which are audit-sensitive, and is unsupported. The package is listed as VALID in the ETRM metadata and is present in both 12.1.1 and 12.2.2 environments.