Search Results register_acceptance

Overview

POS_WF_PO_ACK is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Purchasing document acknowledgement and acceptance workflow. It provides the server-side logic invoked by Oracle Workflow function activities to determine whether supplier acknowledgement is required, to record a supplier's acceptance or rejection of a purchase order or release, and to initialize the workflow attributes that drive the notification process. The package is declared AUTHID CURRENT_USER, so all unqualified object references execute with the privileges of the calling schema, which in practice is the APPS schema under which the Workflow engine runs.

The header comment places the source at version 115.2, dating to November 2002, indicating that the core logic has remained stable across the 12.1.1 and 12.2.2 releases. The documented API classification is OTHER rather than a public or private API designation, which indicates that the package is intended for internal use by the Purchasing workflow rather than as a supported integration interface for external or custom callers.

Key Procedures and Functions

The package exposes six documented procedures, all of which follow the standard Oracle Workflow PL/SQL function activity signature pattern, accepting itemtype, itemkey, actid, and funcmode, and returning a result value. Acceptance_Required evaluates whether a given purchasing document requires supplier acknowledgement or acceptance before the ordering process can proceed. The outcome determines whether the workflow continues down the acknowledgement branch or bypasses it entirely.

Register_Acceptance records the supplier's positive acknowledgement of the document. It updates the acknowledgement state so that the document is treated as accepted and the workflow can advance accordingly.

Register_Rejection is the counterpart to Register_Acceptance and is the procedure most relevant to the search term "register_rejection." It captures a supplier's rejection of a purchase order or release, recording the rejection against the acknowledgement record and setting the attributes that allow the workflow to route the document appropriately, typically prompting buyer review or revision.

Initialize_Attributes and Initialize_AckAttributes populate the workflow item attributes required at the start of the acknowledgement process, ensuring that document identifiers, revision information, and acknowledgement state are available to subsequent activities. Abort_Notification is the only procedure that does not follow the Workflow callback signature; it accepts a document identifier, document revision, and document type, and is used to terminate an outstanding acknowledgement notification when the underlying document changes or is no longer valid.

Tables Accessed

The package reads and writes the acknowledgement tables PO_ACCEPTANCES and PO_ACCEPTANCES_S. PO_ACCEPTANCES holds the current acknowledgement state for a purchasing document, including accept or reject indicators; PO_ACCEPTANCES_S is the corresponding AuditVision-style shadow (DML tracking) table populated by database triggers. Document identity and version context are drawn from PO_HEADERS and PO_HEADERS_ALL for purchase orders, and from PO_RELEASES and PO_RELEASES_ALL for blanket agreement releases. The _ALL tables are the multi-organization base tables, while the non-_ALL views restrict visibility to the current operating unit, consistent with Oracle's multi-org architecture.

Usage Notes

POS_WF_PO_ACK is invoked by the Purchasing acknowledgement workflow, whose function activities reference these procedures by name. The procedures are therefore executed by the Workflow background engine under the APPS schema, not directly by end users. Because the package is not registered as a supported public API and is referenced by zero other packages in the documented metadata, customizations should avoid calling it directly. Where an extension must influence acknowledgement behaviour, extending or replacing the workflow activity definition is the conventional approach, supplemented by updates through the supported Purchasing APIs and concurrent programs. This preserves upgrade safety across 12.1.1 and 12.2.2.