Search Results po_inbound_xml




Overview
Explore in AI Chat

Overview

PO_INBOUND_XML is a PL/SQL package in the APPS schema that supports the inbound processing of Oracle Purchasing documents delivered through XML and EDI-style integration channels. Its principal business function is to receive externally originated purchasing transactions — most notably supplier acknowledgements and buyer-driven quantity, price, and schedule updates — and to apply them reliably against existing purchase orders in the Oracle E-Business Suite database. The package is compiled with AUTHID CURRENT_USER, meaning that privilege resolution occurs under the invoking schema rather than unconditionally as APPS, which is consistent with its role as a conduit invoked from integration and workflow contexts.

The package is catalogued under the API classification OTHER in ETRM for release 12.2.2 and its header comment identifies source file POSYNCIS.pls. It exposes twelve documented program units and references no other packages; it is self-contained in terms of reverse dependencies, acting as a lower-level building block for inbound purchasing document flows.

Key Procedures and Functions

  • TRACE — Writes diagnostic messages at a caller-specified level, providing the debug instrumentation used throughout the package's processing paths.
  • UPDATE_PO — The central function of the package and the target of the "update_po" search. It applies an inbound change to a specific purchasing document, identified by purchase order number down to shipment level, and returns a status number together with API errors. Its parameters carry the new quantity, new price, new promised date, new need-by date, approval launch flag, update source, version, buyer name, secondary quantity, preferred grade, and organization identifier, along with override date handling. This signature shows that it is intended to process supplier acknowledgement data, including changes requested by the supplier and optionally routed to the approval workflow.
  • CANCEL_PO — Cancels a purchasing document or a lower-level document component such as a line, shipment, or release, supporting cancellation against document type, subtype, and identifiers, with action, action date, cancel reason, requisition cancellation flag, print flag, and note-to-vendor.
  • LOG_ERR_MSG — Persists error information collected during processing into the interface error tables, keyed to user, application, responsibility, batch, interface header, and interface line.
  • PROCESS_PO_INBOUND_XML — The orchestration entry point, structured to run as an Oracle Workflow activity (itemtype, itemkey, activity, and function mode), which drives the inbound XML processing lifecycle.
  • IS_PO_NUMBER_EXISTS — Validation utility that confirms whether a purchase order number is already known to the system.
  • GET_OPERATING_UNIT — Resolves the operating unit associated with the inbound document.
  • GET_CLIENT_CODE — Returns the client code used to distinguish inbound message originators.
  • GET_LINE_TYPE — Determines the purchasing line type applicable to the transaction.
  • INITIALISE — Performs setup and initialization before processing begins.
  • GET_TERM_ID — Retrieves the payment terms identifier for the document.

Tables Accessed

Documented table references fall into three groups. First, interface and staging tables: PO_HEADERS_INTERFACE, PO_LINES_INTERFACE, PO_DISTRIBUTIONS_INTERFACE, and PO_INTERFACE_ERRORS with its PO_INTERFACE_ERRORS_S sequence, which hold inbound data and errors prior to and during validation. Second, base purchasing tables that are updated or queried: PO_HEADERS and PO_HEADERS_ALL, PO_LINES, and the PO_DOCUMENT_TYPES and PO_LINE_TYPES lookups that govern document and line classification. Third, supporting reference tables: AP_TERMS for payment terms, ECX_TP_HEADERS and ECX_TP_DETAILS for trading partner identification, FND_USER for user resolution, and MTL_CLIENT_PARAMETERS for client-level configuration.

Usage Notes

PO_INBOUND_XML is not normally invoked directly by end users. It is driven by inbound integration channels, typically the Purchasing Documents Open Interface or the XML/EDI gateway, and PROCESS_PO_INBOUND_XML is designed to execute as a workflow activity, allowing asynchronous, message-based processing of supplier acknowledgements and responses. UPDATE_PO and CANCEL_PO may also be called from custom PL/SQL integrations and concurrent programs that need to apply controlled changes to live purchase orders while honoring approval routing. Because the package listens for and logs errors into PO_INTERFACE_ERRORS, implementors should always inspect the returned API errors record and the interface error tables after invocation. Custom callers should supply the organization identifier explicitly to avoid cross-operating-unit ambiguity.