Search Results save_request




Overview

APPS.PO_CHG_REQUEST_PVT is the private implementation package that underpins Oracle Purchasing's supplier-facing change request functionality in Oracle E-Business Suite 12.1.1 and 12.2.2. Its central responsibility is the orchestration of the change request lifecycle for purchase orders and releases: capturing supplier-initiated requests for changes to quantity, price, promise dates, shipment schedules, or cancellation, persisting those requests, validating them against purchasing rules, and either applying the accepted changes to the purchasing document or recording the cancellation. In addition, the package supports the supplier signature and acceptance flow, generating the notification and acceptance records that represent a supplier's acknowledgement or rejection of a document revision.

The package is classified as a private (PVT) API and carries AUTHID CURRENT_USER, meaning it executes with the privileges of the calling user and is intended to be called from within the Oracle Purchasing application rather than directly by external integrations. It follows the standard EBS API conventions of p_api_version, p_init_msg_list, and an x_return_status output parameter. The process_supplier_request procedure referenced by the search term appears in the package source as a commented-out declaration, indicating that the functionality it once provided has been reorganized into the other documented entry points.

Key Procedures and Functions

The documented interface comprises twenty procedures and functions. The principal public entry points are:

  • PROCESS_SUPPLIER_SIGNATURE — Records a supplier's signature against a purchasing document revision, producing a notification identifier. Two overloads exist, the second accepting a p_draft_id so that signature processing can be tied to an in-progress draft revision.
  • SAVE_REQUEST — Persists a change request from the supplier, accepting a revision number, an optional release identifier, and a change request record table, and returning a request group identifier.
  • PROCESS_SUPPLIER_REQUEST — the subject of the originating search; documented in the package as the routine that posts acceptance and cancellation requests at the shipment level, processes change requests at line and shipment level, invokes time-phased pricing for new prices, splits records into lines, shipments, and distributions, and calls document submission checks for core purchase orders.

Supporting routines include UPDATE_PO_ATTRIBUTES, which applies accepted changes to the header, line, and shipment structures; VALIDATE_CHANGE_REQUEST, IFLINECHANGABLE, VALIDATECANCELREQUEST, VALIDATE_SHIPMENT_CANCEL, VALIDATE_SHIP_INV_CANCEL, and IS_ASN_EXIST, which enforce the rules governing whether a requested change or cancellation is permissible; SAVE_CANCEL_REQUEST and CANCEL_CHANGE_REQUEST, which handle cancellation-specific persistence and processing; CREATE_POS_CHANGE_REC, which builds the change request record; and the utility routines GETSHIPMENTSTATUS, GETLINEATTRS, GETMAXSHIPMENTNUM, and GETLASTUPDATEDATE.

Tables Accessed

The package reads and writes the core Purchasing document tables through APPS synonyms. PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, and PO_RELEASES_ALL hold the live document, line, shipment, and release data that change requests target. Their archive counterparts, PO_LINES_ARCHIVE_ALL and PO_LINE_LOCATIONS_ARCHIVE_ALL, support revision history. PO_LINE_TYPES supplies line classification. PO_CHANGE_REQUESTS and the PO_CHG_REQUEST_SEQ sequence store and number change request records. PO_ACCEPTANCES and FND_NEW_MESSAGES support the supplier acknowledgement and notification process, while FND_USER resolves supplier and agent identities. PO_HAZARD_CLASSES_TL and PO_UN_NUMBERS_TL are referenced for hazardous-material and UN number attributes carried on the document.

Usage Notes

PO_CHG_REQUEST_PVT is invoked indirectly by Oracle Purchasing forms, by the supplier portal and iSupplier negotiation flows, and by the concurrent programs that process supplier change requests and acceptance notifications. It is referenced by four other packages within the application, which call its procedures rather than re-implementing change request logic. Because the package is private and its specification is not a committed public interface, custom code should generally invoke the supported public Purchasing APIs or use the supplier-facing flows rather than calling these procedures directly; direct calls risk breakage across patch levels. The package relies on the FND message stack for error reporting and expects callers to check x_return_status before proceeding.