Search Results po_forward_sv1




Overview
Explore in AI Chat

Overview

APPS.PO_FORWARD_SV1 is a server-side PL/SQL package body in the Oracle E-Business Suite Purchasing module (Oracle Purchasing / iProcurement). Its primary responsibility is to centralize the logic used to write records into the PO_ACTION_HISTORY table, which functions as the audit trail for the purchasing approval workflow. Whenever a document such as a purchase order, release, or associated approval path transitions between states — submitted, approved, rejected, forwarded, or withdrawn — a corresponding action history row must be recorded. PO_FORWARD_SV1 provides the callable interface that performs this insert on behalf of form logic, workflow activities, and other packages. The package header declares the same procedures exposed publicly, allowing other program units in the APPS schema to invoke the action-history logging routines without duplicating the underlying insert logic.

Key Procedures and Functions

  • INSERT_ACTION_HISTORY — The core procedure of the package. It accepts the full set of action-history attributes (object identifiers, object type and sub-type, sequence number, action code, action date, employee, approval path, note, revision number, offline code, concurrent request identifiers such as request_id, program_application_id and program_id, program date, user_id, and login_id) and, after any necessary preparation, inserts a single row into PO_ACTION_HISTORY. This is the procedure most commonly invoked directly by other packages and forms.
  • TEST_INSERT_ACTION_HISTORY — A wrapper or diagnostic entry point that mirrors the INSERT_ACTION_HISTORY signature. It is used during development, unit testing, or troubleshooting to invoke INSERT_ACTION_HISTORY with a known set of parameters so that the resulting PO_ACTION_HISTORY row can be validated. It confirms the call executes and leaves verification of the inserted data to the caller.
  • INSERT_ALL_ACTION_HISTORY — A bulk or wrapper procedure intended to log action history across multiple objects or action sets in a single invocation. It builds on the single-row insert logic to satisfy scenarios in which several action-history records must be written as part of one workflow event.
  • UPDATE_ALL_ACTION_HISTORY — The counterpart to the "insert all" routine, providing update handling for previously recorded action-history entries. This supports corrections or state refinements to existing audit rows when the workflow requires amending rather than simply appending a history record.
  • NAME/header declarations — The documented inventory also lists the package NAME (public declaration) alongside the procedures above; ten documented procedures/functions exist in total, though the excerpt exposes only the leading subset.

Tables Accessed

  • PO_ACTION_HISTORY — The central table written by this package. Each call to INSERT_ACTION_HISTORY (or its wrapper variants) inserts a row capturing the object being acted upon, the action taken, the date and the acting employee, the approval path, and auditing columns such as request_id, program identifiers, program date, user_id, and login_id. This table is the persistence layer for the purchasing approval audit trail.
  • FND_USER — Referenced via an APPS synonym, typically to resolve or validate the acting user responsible for the action recorded in history, ensuring the audit trail is tied to a legitimate application user identity.

Usage Notes

PO_FORWARD_SV1 is invoked primarily from the Oracle Purchasing and iProcurement approval workflow and the associated OAF/Forms approval pages. When a user forwards a document for approval, approves, rejects, or withdraws it, the calling form or workflow function routes the action through this package so that PO_ACTION_HISTORY remains synchronized with the document's workflow state. Because it is referenced by twelve other packages, it functions as a shared service utility rather than a private helper; any change to its public signatures can ripple across those dependent units, so modifications must be regression-tested carefully. Customizations that need to record a purchasing approval action programmatically should call INSERT_ACTION_HISTORY rather than inserting directly into PO_ACTION_HISTORY, so that the standard column population and any internal precondition checks are honored. Developers diagnosing a missing or malformed "Action History" entry — a frequent symptom when the user searches for insert_action_history — should verify that the calling workflow activity successfully reached PO_FORWARD_SV1.INSERT_ACTION_HISTORY and that the concurrent request context (request_id, program_id, program_application_id) was passed, because those auditing columns are populated from the caller's environment. In EBS 12.1.1 and 12.2.2 the package remains part of the standard APPS schema and is not itself intended for direct end-user execution; it is always driven by workflow, form, or other server-side code.