Search Results update_poline

Overview

ITG_SYNCPOINBOUND_PVT is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified as a private (PVT) API within Oracle's ETRM (E-Business Suite Technical Reference Manual) metadata. The package belongs to the ITG (Integrated Transaction Gateway) family of synchronization programs that support inbound integration of purchasing transactions into Oracle Purchasing. Its principal business function is to accept inbound purchase order line data delivered through the SYNC_PO XML interface and apply updates to the corresponding purchasing documents — purchase order lines, blanket purchase agreement releases and their associated distributions — based on an action flag supplied by the calling process.

The package conforms to the Oracle Application Object Library (FND_API) business object API standard, honouring the conventional API version, initialization, commit and validation level input arguments together with the standard return status and message count/data output arguments. This design allows the procedure to participate in a larger error-handling and message-stack framework and to be invoked safely from other PL/SQL APIs, concurrent programs or inbound XML message handlers.

Key Procedures and Functions

The documented metadata exposes a single procedure: UPDATE_POLINE. As its name implies, it updates an existing purchase order line rather than creating a new one. The procedure locates the target purchase order using the caller-supplied PO identifier string and organization identifier, optionally resolving a blanket purchase agreement release when a release identifier is provided. It then identifies the specific line by line number and applies the requested change.

The type of update performed is governed by a document type / action flag that indicates whether the inbound message relates to RECEIPT, INSPECTION or INVOICE processing. Where the action concerns invoicing, the procedure applies a monetary amount; for the other action types, a quantity is applied to the line. In this manner a single procedure supports multiple inbound synchronization scenarios while preserving the standard API calling convention.

Tables Accessed

The package reads and writes the core Oracle Purchasing base tables through APPS synonyms:

• PO_HEADERS_ALL — used to resolve the purchase order or blanket agreement header identified by the inbound PO code and organization.
• PO_LINES_ALL — the primary target of the update, holding the line being modified.
• PO_LINE_LOCATIONS and PO_LINE_LOCATIONS_ALL — shipment and schedule information associated with the affected line.
• PO_DISTRIBUTIONS_ALL — distribution-level quantities and amounts adjusted in line with the line update.
• PO_RELEASES_ALL — consulted when the inbound transaction references a release against a blanket purchase agreement.
• PO_REQUISITION_LINES_ALL — referenced for associated requisition information linked to the purchasing document.
• PLITBLM — an internal temporary/interface table used to stage inbound line item data before it is applied.

Together these tables represent the full purchasing document hierarchy from header through line, shipment, distribution and release, consistent with the procedure's role in maintaining synchronization between external transaction sources and Oracle Purchasing.

Usage Notes

This is a private API and is not intended for direct invocation by end users or general custom code; it is designed to be called by the ITG_SYNCPOINBOUND integration layer that processes inbound SYNC_PO messages. The procedure is typically invoked from concurrent-program or message-processing infrastructure that parses the inbound XML, maps tags such as POID, SITELEVEL, PORELEASE and POLINENUM to the procedure's functional arguments, and then calls Update_PoLine.

Because the procedure observes the FND_API conventions, callers should supply the current API version, control message-list initialization and commit behaviour through the standard flags, and inspect the return status before inspecting the message stack via FND_MSG_PUB when more than one message is returned. ETRM metadata records that the package is referenced by one other package, confirming its role as a private implementation component rather than a public integration point.