Search Results hide_nonfunded




Overview
Explore in AI Chat

Overview

PO_CLM_INTG_GRP is a PL/SQL integration package owned by APPS and defined with AUTHID CURRENT_USER. Its name reflects its role as the integration bridge between Oracle Purchasing and Oracle Contracts Lifecycle Management (CLM), the contract authoring and funding module that ships with Oracle E-Business Suite. The package supplies the runtime logic that answers two recurring questions in a mixed purchasing environment: is a given document a CLM document, and if so, how is it funded? It also provides the mechanism by which unfunded lines are suppressed from display in the purchasing user interface.

Because CLM-managed documents participate in the same tables as conventional purchase orders and requisitions, purchasing forms and concurrent programs must be able to distinguish the two populations at runtime. PO_CLM_INTG_GRP centralises that determination so that the many callers in the application do not each re-implement it. The package is classified as an API group (GRP), meaning it is a collection of related entry points rather than a single transactional API, and it is referenced by 52 other database objects within the E-Business Suite. The copy documented here carries a header revision of 120.4, last modified 7 April 2010.

Key Procedures and Functions

  • IS_CLM_PO — Determines whether a purchase order entity constitutes a CLM purchase order. It accepts any one of the purchasing document identifiers, allowing the caller to pass whichever key is available at the point of invocation, and returns a VARCHAR2 status indicator.
  • IS_CLM_INSTALLED — Reports whether the CLM module is installed in the current instance. Callers use this to short-circuit CLM-specific processing so that the same code can run in environments where CLM is absent.
  • IS_CLM_DOCUMENT — Generalises the CLM test beyond purchase orders. Given a document type and document identifier, it returns a VARCHAR2 value indicating whether the referenced document is CLM-managed, extending the check to requisition documents as well as orders.
  • GET_FUNDING_INFO — Returns the PO funding information for a given entity. The sole documented output parameter is X_RETURN_STATUS, which conveys the outcome of the call; the remaining funding attributes are populated by the procedure for the caller.
  • HIDE_NONFUNDED — The function, and the entry point most commonly associated with this package. Given a document type, a header identifier, and optional line, line location, and distribution identifiers, it determines whether a non-funded entity should be hidden from the user. It is the mechanism behind the "hide nonfunded" behaviour observed in the purchasing forms, and it is the reason the package is invoked so broadly across the application.

Tables Accessed

The package reads and writes the core Purchasing tables through APPS synonyms. PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL and PO_DISTRIBUTIONS_ALL provide the purchase order document hierarchy that the CLM and funding tests evaluate. PO_REQUISITION_HEADERS_ALL, PO_REQUISITION_LINES_ALL and PO_REQ_DISTRIBUTIONS_ALL supply the equivalent requisition hierarchy, supporting the document-type branching in IS_CLM_DOCUMENT and HIDE_NONFUNDED. PO_DOC_STYLE_HEADERS is the document style definition table, which carries the style attributes that distinguish CLM-authored documents from standard ones; it underpins IS_CLM_PO and IS_CLM_DOCUMENT. The presence of PO_DISTRIBUTIONS_ALL in this list is consistent with GET_FUNDING_INFO and HIDE_NONFUNDED being distribution-level enquiries.

Usage Notes

PO_CLM_INTG_GRP is an internal integration package rather than a public API. Its 52 referencing objects indicate that it is called from Oracle Purchasing forms — most visibly wherever unfunded lines are filtered from a folder or block — and from concurrent programs and other package-level processing that must behave differently for CLM documents. The DEFAULT NULL signatures on the identifier parameters of IS_CLM_PO and HIDE_NONFUNDED are deliberate: callers pass only the key relevant to their context. Customisations should call IS_CLM_INSTALLED before any other entry point to remain safe in instances where CLM is not deployed, and should treat X_RETURN_STATUS from GET_FUNDING_INFO as the authoritative success indicator rather than assuming output values are populated. Because the package is AUTHID CURRENT_USER, callers execute against their own schema privileges, so grants on the underlying Purchasing tables matter. Direct modification of this package is not supported; the documented revision level should be preserved.