Search Results po_pdoi_grp




Overview
Explore in AI Chat

Overview

APPS.PO_PDOI_GRP is the group-level (GRP) PL/SQL package body that fronts the Purchasing Document Open Interface (PDOI) processing framework in Oracle E-Business Suite. PDOI is the standard inbound interface through which external systems, legacy conversions, and batch loads create and update purchasing documents — requisitions, purchase orders, blanket and contract agreements, quotations, and their associated lines, shipments, distributions, and price breaks — without direct table-level manipulation. The "GRP" classification indicates that this package exposes the procedural entry points and orchestration logic for that interface rather than encoding the low-level validation and insert/update rules themselves.

PO_PDOI_GRP sits at the top of a layered architecture. It depends on PO_PDOI_PVT (the private validation and processing engine), PO_PDOI_CONSTANTS (interface constants and status codes), PO_GLOBAL (global Purchasing variables and profile-driven settings), PO_LOG (debug and trace logging), FND_MSG_PUB (the Oracle Application Object Library message dictionary), FND_API (the standard API error-handling framework), PO_MESSAGE_S and the STANDARD package. Consistent with a grouping wrapper, it is not referenced by any other database object; the dependency flow is one-directional, with the package calling downward into the private engine and no inbound callers inside the schema.

Key Procedures and Functions

  • START_PROCESS — The primary orchestration entry point for a PDOI run. It drives the end-to-end interface cycle: identifying eligible records in the purchasing interface staging tables, invoking the private processing engine for validation and application of each batch, collecting and publishing errors through FND_MSG_PUB, and returning overall request status. It is the routine most commonly called from a concurrent program shell.
  • CATALOG_UPLOAD — Handles the upload of catalog content associated with purchasing documents, supporting the loading of supplier and internal catalog data referenced by requisition and purchase order interface records. It coordinates parsing, validation, and persistence of catalog structures through the private layer.
  • HANDLE_PRICE_TOLERANCE_RESP — Manages the response path for price tolerance validation. When an interface record breaches configured price tolerance rules, this routine governs how the exception is recorded and resolved, including surfacing the corresponding message and determining whether the record proceeds, is flagged, or is rejected.

No parameter lists are documented in the ETRM metadata and none are inferred here; callers should obtain signatures from the package specification in the target environment.

Tables Accessed

The ETRM documentation for this object records no directly referenced base tables via APPS synonyms. This is expected: PO_PDOI_GRP delegates SQL access to PO_PDOI_PVT and the interface constants layer, so the physical reads and writes against the PDOI interface tables (the PO_HEADERS_INTERFACE, PO_LINES_INTERFACE, PO_DISTRIBUTIONS_INTERFACE and related staging structures) occur in the lower layers. The metadata does confirm functional references to PO_MESSAGE_S for message text retrieval and to the FND message framework for error publication.

Usage Notes

PO_PDOI_GRP is a server-side integration package and is not attached to an Oracle Forms UI. It is invoked from the concurrent manager, typically through the Purchasing Documents Open Interface concurrent program and related catalog and price tolerance processes, and from custom PL/SQL that loads the interface staging tables and then calls the group entry point to run validation and import. It is supported on Oracle EBS releases 12.1.1 and 12.2.2 with a VALID status in the APPS schema.

Because the package is a grouping wrapper over PO_PDOI_PVT, customizations should prefer modifying or extending the private engine only where Oracle permits and should use the FND message framework so that errors raised by START_PROCESS and HANDLE_PRICE_TOLERANCE_RESP are surfaced consistently in the concurrent request log. Robust implementations should commit or roll back staging data before invoking the group routine, rely on PO_LOG for diagnostics at elevated logging levels, and never call the private PVT routines directly when the group entry point is available.