Search Results create_header_process




Overview
Explore in AI Chat

Overview

POS_ACK_PO is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the supplier-facing purchase order acknowledgement and acceptance workflow within Oracle Purchasing. Its principal business purpose is to capture a supplier's response to a buyer's purchase order or release — specifically whether the supplier accepts, rejects, or proposes changes to the order — and to drive the corresponding Oracle Workflow notification and document lifecycle. Typical supplier actions such as accepting a PO, rejecting a PO, or promising a revised date on a line are processed through the procedures in this package, which then update the purchasing tables and advance the acknowledgement workflow. The package is part of the supplier collaboration integration layer and is referenced directly or indirectly by other application modules, as reflected in the documented fact that it is referenced by five other packages.

Key Procedures and Functions

  • ACKNOWLEDGE_PO — The central procedure for recording a supplier's acknowledgement of a purchase order. It accepts identifiers for the PO header and optionally the release and line, the buyer, the accept/reject indicator, an acceptance type code, and acknowledgement comments, along with the acting user. The version documented reflects Bug 6772960, which added the l_last_update_date parameter for optimistic concurrency control: because multiple supplier users may act on the same PO simultaneously, the procedure compares the supplied last update date against the current value and returns an error through the x_error output parameter when another user has already modified the record.
  • ACKNOWLEDGE_PROMISE_DATE — Defaults a line location's promise date to its need-by date. This is described in the source as a new procedure introduced for promise date handling and operates on a specific line location under a PO header or release and revision.
  • CREATE_HEADER_PROCESS — Creates the header-level workflow process instance for a PO (or release), returning the item type and item key that identify the workflow instance.
  • START_HEADER_PROCESS — Starts the header workflow process using the item type and item key produced by CREATE_HEADER_PROCESS.
  • ADD_SHIPMENT — Adds or updates shipment-level acknowledgement detail, capturing new and old promise dates and need-by dates together with a reason, under the workflow item type and key.
  • POS_ACK_HEADER_PROCESS — Documented as a package procedure; the source shows the definition is commented out, and its role aligns with initiating the header-level acknowledgement process, a function now primarily handled by the CREATE_HEADER_PROCESS / START_HEADER_PROCESS pair.

Tables Accessed

The package reads and writes purchasing acknowledgement data through APPS synonyms. PO_HEADERS_ALL and PO_RELEASES_ALL are used to identify and validate the purchase order or release being acknowledged. PO_ACCEPTANCES and its shadow table PO_ACCEPTANCES_S store the supplier acceptance or rejection records and comments. PO_LINE_LOCATIONS_ALL and PO_LINE_LOCATIONS_ARCHIVE_ALL hold the shipment and promise/need-by date information updated by ADD_SHIPMENT and ACKNOWLEDGE_PROMISE_DATE. Oracle Workflow tables — WF_ITEM_ACTIVITY_STATUSES, WF_NOTIFICATIONS, and PO_WF_ITEMKEY_S — support the notification and process status tracking that accompany the acknowledgement workflow. FND_NEW_MESSAGES is used for delivering user feedback, and DUAL serves for simple single-row queries.

Usage Notes

POS_ACK_PO is typically invoked from the supplier-facing acknowledgement user interface and from Oracle Workflow function activities that respond to supplier actions such as acceptance, rejection, or a promised-date change. It may also be called from the supplier collaboration concurrent processes that reconcile acknowledgement messages. Customizations and integrations that need to programmatically acknowledge a PO on a supplier's behalf should call ACKNOWLEDGE_PO within the standard API error-handling conventions, passing the header/release identifiers, the accept/reject indicator, the acceptance type code, comments, and the user id, and must supply the last update date value to preserve the concurrency check introduced by Bug 6772960. Callers should inspect the x_error output parameter to detect a concurrent-modification conflict and surface it to the supplier user rather than retrying blindly.