Search Results catalog_upload

Overview

APPS.PO_PDOI_GRP is a group (GRP) type PL/SQL package within the Oracle E-Business Suite Purchasing module. Its name derives from "PO PDOI," referencing the Purchasing Document Open Interface (PDOI), the batch-oriented interface mechanism through which purchasing documents such as purchase orders, quotations, and blanket agreements are loaded into Oracle Purchasing from external sources. The package serves as the orchestration layer for the PO Document Open Interface processing engine, coordinating validation, import, and error-handling activity across the interface staging tables.

The package is documented in ETRM 12.2.2 and carries a header revision marker of 120.4, a legacy versioning prefix indicating that the code originates from the 12.0.x development line and has been carried forward into 12.1.1 and 12.2.2 without structural change. The "noship" designation in the header confirms the file is shipped as compiled object code within the APPS schema.

Key Procedures and Functions

Three documented procedures constitute the public interface of this package.

• START_PROCESS — The principal entry point for submitting a PO Document Open Interface batch. It accepts the Oracle-standard API parameters (API version, message list initialization, validation level, commit flag, and return status) alongside operational controls that govern which records are processed (selected batch identifier, batch size, buyer, document type and subtype), how related objects are created (item creation, sourcing rule creation, release generation method, sourcing level and inventory organization), the approval status applied to imported documents, and organization security context.
• CATALOG_UPLOAD — The procedure associated with the user's search term. It extends the standard interface submission pattern to support catalog content, adding controls for draft submission, role context, catalog expiration, and an error-line tolerance threshold. Unlike START_PROCESS, it returns not only a status but also an error message, a count of processed lines, a count of rejected lines, and a flag indicating whether the configured error tolerance was exceeded — making it suitable for high-volume catalog loads where partial success is acceptable.
• HANDLE_PRICE_TOLERANCE_RESP — A supporting procedure that manages the response path when a price tolerance exception is raised during interface processing. It allows the calling process to resolve or acknowledge tolerance violations rather than failing the entire batch.

Tables Accessed

The ETRM metadata for this object does not enumerate specific base tables. By architectural convention, PO_PDOI_GRP operates against the PO Document Open Interface staging schema — principally PO_INTERFACE_HEADERS_ALL and PO_INTERFACE_LINES_ALL, which hold header- and line-level interface records — and the corresponding error tables PO_INTERFACE_ERRORS that capture validation failures. Final imported documents are written to the core purchasing tables (PO_HEADERS_ALL, PO_LINES_ALL, and their distribution and location children) through the standard interface import routines rather than directly by this group package.

Usage Notes

PO_PDOI_GRP is typically invoked rather than called directly by end users. The standard invocation path is the Purchasing Documents Open Interface concurrent program, which calls START_PROCESS after data has been staged in the interface tables. The CATALOG_UPLOAD entry point is used by catalog and punchout-related loading processes, where tolerance-based partial acceptance is required.

Because the package conforms to the Oracle APIs coding standard, custom integrations may call these procedures directly, provided callers honor the API version, initialize the message list when requested, and check X_RETURN_STATUS before committing. Callers should also inspect the line-count and tolerance outputs returned by CATALOG_UPLOAD. Given the "noship" header and revision 120.4, the package should be treated as a stable internal component; custom code should depend on it only through the documented procedure signatures.