Search Results get_payment_style_settings

Overview

APPS.PO_COMPLEX_WORK_GRP is a public PL/SQL group package (API classification: GRP) in the Oracle E-Business Suite Purchasing module. It encapsulates the business rules that govern complex work and financing payment structures on purchase orders. Complex work is used for long-term, service-oriented or construction-style procurement where payment is not a single lump sum but is disbursed through milestones, rate schedules, advances, retainage, or other financing arrangements. The package exposes a small, stable interface that lets other EBS components ask two fundamental questions: does a given payment style represent complex work or financing, and is a given purchase order header associated with such characteristics. Internally it delegates to PO_COMPLEX_WORK_PVT, the private implementation package, and simply re-exposes global constants and wrapper procedures. All entry points carry the AUTHID CURRENT_USER clause, meaning they execute with the privileges of the calling schema rather than the definer, which is significant when custom code invokes them.

Key Procedures and Functions

The package declares five documented procedures and a set of package-global constants for the recognized payment types: MILESTONE, RATE, LUMPSUM, ADVANCE, and DELIVERY. These constants mirror those defined in PO_COMPLEX_WORK_PVT so callers can compare style flags without hard-coding literal strings.

• GET_PAYMENT_STYLE_SETTINGS — Returns the complete set of complex-work settings configured for a payment style, including whether the style is complex work, allows financing payments, permits retainage, and allows advance, milestone, lump sum, and rate payment types.
• IS_COMPLEX_WORK_STYLE — Determines whether a specified payment style identifier is classified as a complex work style and returns a boolean-style flag.
• IS_FINANCING_PAYMENT_STYLE — The procedure most relevant to the search term is_financing_payment_style. It evaluates a payment style and indicates whether that style supports financing payments, allowing callers to branch logic without querying configuration tables directly.
• IS_COMPLEX_WORK_PO — Evaluates a purchase order header and reports whether the order is a complex work purchase order.
• IS_FINANCING_PO — Evaluates a purchase order header and reports whether the order is a financing purchase order.

The style-oriented procedures operate on a style identifier, while the PO-oriented procedures operate on a PO header identifier, giving callers symmetrical coverage of both the configuration and transactional dimensions.

Tables Accessed

The ETRM metadata for this object does not list any tables accessed directly via APPS synonyms. As a thin group-layer wrapper, PO_COMPLEX_WORK_GRP does not perform DML of its own; any reads of Purchasing setup or transaction tables occur inside PO_COMPLEX_WORK_PVT, which this package calls. Consumers inspecting data lineage should therefore trace table access to the private package and the payment style and purchase order header entities it references. The group package itself is effectively stateless apart from the compile-time constants.

Usage Notes

The package is referenced by three other documented packages, confirming its role as a shared utility rather than a standalone entry point. Typical invocation patterns include Oracle Forms in the Purchasing and iProcurement flows, which call the financing and complex-work checks when rendering payment terms for a supplier or a draft order, and concurrent or workflow programs that validate whether an order qualifies as financing before routing it for approval. Custom extensions should follow the same conventions: pass a valid API version, expect a return status for error handling, and treat the flag outputs as authoritative rather than re-deriving the logic from base tables. Because the procedures are defined with AUTHID CURRENT_USER, custom callers must be granted execute privilege on the package and must have whatever underlying object privileges PO_COMPLEX_WORK_PVT requires. The package is versioned as 120.0, dated 2005, and ships as a "noship" header, indicating a long-standing, stable API in both EBS 12.1.1 and 12.2.2.