Search Results po_complex_work_pvt




Overview
Explore in AI Chat

Overview

APPS.PO_COMPLEX_WORK_PVT is a private PL/SQL package body in the Oracle Purchasing module of Oracle E-Business Suite, valid in both release 12.1.1 and 12.2.2. The "PVT" suffix denotes a private API classification within the Oracle EBS coding convention: the package encapsulates internal business logic that is invoked by other Purchasing packages rather than being published directly to external integrators. Its functional domain is complex work and financing payment styles on purchasing documents. Complex work and financing arrangements are used when a procurement transaction spans multiple payment phases or involves a third-party financier, requiring Oracle Purchasing to determine whether a document, its style, or its payment items qualify for that special handling.

The package provides the determination logic that drives defaulting and validation behavior in the Purchasing forms and in the underlying document creation APIs. Because it is a private package, callers are expected to be Oracle-owned Purchasing code, not custom client code.

Key Procedures and Functions

The documented package exposes ten procedures and functions in total. The named entries fall into three functional groups.

  • IS_COMPLEX_WORK_STYLE and IS_COMPLEX_WORK_PO — boolean-style checks that determine whether a given document style, or a specific purchase order, is classified as complex work.
  • IS_FINANCING_PAYMENT_STYLE and IS_FINANCING_PO — parallel checks that determine whether a payment style, or a specific purchase order, is governed by financing payment terms.
  • GET_PAYMENT_STYLE_SETTINGS — retrieves the configuration attributes defined for a payment style, allowing the calling program to obtain the settings that govern payment behavior on the document.
  • GET_DEFAULT_PAYITEM_INFO and GET_ADVANCE_AMOUNT — defaulting and derivation routines. GET_DEFAULT_PAYITEM_INFO supplies default payment item information for a document line or shipment, while GET_ADVANCE_AMOUNT derives the advance or prepayment amount associated with the financing or complex work arrangement.

The remaining procedures perform supporting internal work within the same domain and are invoked by the functions listed above and by sibling Purchasing packages.

Tables Accessed

Dependency metadata shows the package references the following objects through APPS synonyms:

  • PO_DOC_STYLE_HEADERS and PO_DOC_STYLE_GRP — document style definitions; the package reads these to resolve style attributes and determine whether a style is a complex work or financing style.
  • PO_HEADERS and PO_HEADERS_ALL — the base purchasing document headers; used by the IS_*_PO checks to evaluate the header-level style and financing attributes of a specific order.
  • PO_LINE_LOCATIONS_ALL and PO_LINE_LOCATIONS_ARCHIVE_ALL — shipment and distribution schedule data including the archive variant; used when resolving payment item defaults and advance amounts at the schedule level.
  • PO_STYLE_ENABLED_PAY_ITEMS — the mapping that identifies which payment items are enabled for a given style; consumed by the payment defaulting routines.
  • PO_LOG, PLITBLM, and STANDARD — used for debug logging, PL/SQL table and string utilities, and the standard Oracle EBS error-handling and message framework respectively.

Usage Notes

PO_COMPLEX_WORK_PVT is not referenced by any database object in the reporting schema, meaning it is not a dependency of other stored objects captured in that metadata; it is, however, referenced by roughly twenty-five other packages at runtime, confirming its role as a shared internal utility. It is typically invoked indirectly — from the Purchasing forms when a user selects a document style or enters a payment schedule, and from the document creation and update APIs during defaulting and validation. Because of the PVT classification, customizations should not call these routines directly; the supported extension points are the public Purchasing APIs and the underlying style and payment item setups. Any modification to the package must be performed with respect to the documented dependencies on PO_HEADERS_ALL and the line location tables, since the determination logic depends on current header and schedule state.