Search Results po_change_api1_s




Overview
Explore in AI Chat

Overview

APPS.PO_CHANGE_API1_S is a public PL/SQL package that forms part of the Oracle Purchasing application programming interface layer in Oracle E-Business Suite releases 12.1.1 and 12.2.2. Its principal business function is to support controlled, programmatic modification of purchasing documents — most notably purchase orders and their acceptance records — without requiring users to traverse the standard Purchasing forms. The package encapsulates the validation and persistence logic needed to apply changes to purchasing data in a manner consistent with Oracle's documented API conventions, thereby protecting the integrity of the underlying purchasing transaction tables.

The package is classified under the "OTHER" API category, reflecting its role as a supporting utility rather than a primary business-document creation API. Its status is recorded as VALID in the ETRM repository, and it resides in the APPS schema alongside the other Oracle Purchasing public APIs. The excerpted documentation notes both package specification and package body entries, indicating that the callable interface and its implementation are separately maintained objects within the data dictionary.

Key Procedures and Functions

The documented metadata identifies five callable programs within PO_CHANGE_API1_S. Their names indicate the following responsibilities:

  • UPDATE_PO — The primary entry point for applying changes to an existing purchase order. It serves as the workhorse procedure through which modified purchasing attributes are validated and committed to the base tables.
  • VALIDATE_ACCEPTANCE — Performs pre-update verification of acceptance information associated with the purchasing document, ensuring that the proposed acceptance data satisfies business rules before any write operation occurs.
  • RECORD_ACCEPTANCE — Persists validated acceptance detail against the purchase order, creating or amending the corresponding acceptance records.
  • CHECK_MANDATORY_PARAMS — An internal consistency routine that confirms all required parameters have been supplied by the caller prior to executing the substantive change logic. Invoking this check first prevents partial or malformed updates.
  • INSERT_ERROR — A diagnostic helper that writes error information to the interface error infrastructure when validation or processing fails, allowing callers to retrieve and interpret failure conditions.

As the excerpt does not publish formal parameter lists, callers should consult the package specification in the target instance for exact signatures.

Tables Accessed

The package operates against a defined set of Purchasing tables, referenced through APPS synonyms:

  • PO_HEADERS and PO_HEADERS_ALL — The core purchase order header records that UPDATE_PO modifies.
  • PO_ACCEPTANCES — Stores the acceptance detail created or amended by RECORD_ACCEPTANCE and examined by VALIDATE_ACCEPTANCE.
  • PO_RELEASES — Release-level purchasing data that may be affected by change operations against the parent agreement or order.
  • PO_INTERFACE_ERRORS and PO_INTERFACE_ERRORS_S — The interface error tables populated by INSERT_ERROR when processing exceptions arise.

The dependency list further records a reference to the PO_API_ERRORS_REC_TYPE and the STANDARD package, which supply error-record typing and standard utilities respectively.

Usage Notes

PO_CHANGE_API1_S is typically invoked programmatically rather than interactively. It is referenced by several other packages, including DPP_PURCHASEPRICE_PVT, JMF_SHIKYU_RECONCILIATION_PVT, PO_INBOUND_XML, and recursively by the package itself, indicating use in inbound XML processing, procurement price derivations, and reconciling supplier invoicing flows. Custom code should follow the documented sequence: call CHECK_MANDATORY_PARAMS, then VALIDATE_ACCEPTANCE where acceptance data is involved, then UPDATE_PO and/or RECORD_ACCEPTANCE, inspecting PO_INTERFACE_ERRORS for failures. Because the package is a public API resident in APPS, standard EBS grants and the usual API coding conventions apply.