Search Results inv_quantity_tree_pub




Overview
Explore in AI Chat

Overview

INV_QUANTITY_TREE_PUB is the public application programming interface for Oracle Inventory's quantity tree engine. The quantity tree is the hierarchical structure Oracle EBS uses to project on-hand, available, and reservable balances for an item at a given organization and, where applicable, a given revision, lot, subinventory, or locator. Rather than forcing calling code to query the transaction tables and derive balances directly, the quantity tree caches projected quantities in a hierarchical cache and answers "what is the quantity?" questions through a controlled, API-driven interface. INV_QUANTITY_TREE_PUB is the supported entry point for that interface within the APPS schema.

Because it is classified as a PUB package, INV_QUANTITY_TREE_PUB is intended to be called by external consumers. The package body delegates the substantive work to INV_QUANTITY_TREE_PVT (the private implementation) and INV_QUANTITY_TREE_GRP, using FND_API, FND_MESSAGE, FND_MSG_PUB, and FND_PROFILE for the standard EBS API error-handling and profile-option conventions, and INV_GLOBALS for Inventory-specific globals. It is validated and currently VALID in both the 12.1.1 and 12.2.2 environments.

Key Procedures and Functions

  • CLEAR_QUANTITY_CACHE — Invalidates the in-memory quantity cache so that subsequent queries re-derive projected quantities from the underlying data. This is typically invoked after operations that change on-hand, reservations, or item/organization setup.
  • QUERY_QUANTITIES — The primary read interface. Returns projected quantity information for a specified item, organization, and related dimensions from the quantity tree cache, creating or refreshing the cache node as required.
  • UPDATE_QUANTITIES — Applies incremental quantity changes to the cached quantity tree without a full re-derivation. Used by transaction and reservation flows to keep the projection current.
  • DO_CHECK — A validation/consistency routine used internally by the package to verify quantity tree state and inputs. It is exposed alongside the public procedures but serves as a supporting check rather than a transactional entry point.

The body also contains the standard EBS API scaffolding (message initialization and standardized exception handling) that underpins these procedures.

Tables Accessed

The package body references the MTL_PARAMETERS table through its APPS synonym. MTL_PARAMETERS holds organization-level Inventory parameters, including the negative-inventory and quantity-tracking settings that govern whether and how the quantity tree may project balances. These parameters are read to determine the correct behavior for the target organization before any quantity query or update is performed. The remaining quantity data is managed through the private package and group layers rather than by direct SQL in the public body.

Usage Notes

INV_QUANTITY_TREE_PUB is widely embedded in the Inventory transaction and reservation stack. The ETRM metadata records that it is referenced by 71 other packages, and it is not itself referenced by any database object — confirming its role as a leaf-level public service consumed by a large body of dependent code.

Typical invocations include:

  • Inventory forms and internal transaction processing that need projected quantities before committing a transaction.
  • Reservation and shipping flows that must confirm availability against the cached tree.
  • Concurrent programs and custom extensions performing availability checks, where QUERY_QUANTITIES is called to obtain a balance in preference to querying MTL_ONHAND_QUANTITIES directly.

Oracle recommends using this API rather than reading or writing the quantity tables directly, because the package maintains cache consistency and honors organization parameters such as negative-inventory control. Callers should follow the standard EBS API pattern: check the returned status before proceeding. Because it is a PUB object, INV_QUANTITY_TREE_PUB is considered a supported integration surface, though the parameter signatures and internal behavior should be treated as Oracle-managed and validated against the specific patch level in use.