Search Results get_total_dist_qty




Overview

PO_DIST_S is a server-side PL/SQL package in the Oracle E-Business Suite Purchasing module (APPS schema) that exposes the Distribution APIs used by Purchasing forms and internal processing logic. Its principal business function is to manage and validate the distribution records that split a purchase order shipment into accounting and receiving allocations. Distributions against a shipment determine how ordered quantities and charges are apportioned across destinations, projects, and accounts, and they are essential to downstream receiving, matching, and accounting activity. The package header carries a header comment identifying the owner as KPOWELL, with the source revision history ($Header: POXPOPDS.pls 120.1.12000000.2) dated 2007, indicating the package has been stable across the 12.1.1 and 12.2.2 releases with no functional change recorded between them. Within the APPS schema, PO_DIST_S serves as the application-side access layer over the PO_DISTRIBUTIONS table, providing quantity defaulting and existence validation services to the distribution block of the purchase order entry form and to any programmatic caller that needs to reason about shipment distributions.

Key Procedures and Functions

The ETRM metadata documents five named program units in the package. GET_TOTAL_DIST_QTY is the unit most commonly searched for: it computes the total quantity already distributed against a given shipment so that the remaining quantity can be defaulted onto a new distribution line. It accepts a PO_LINE_LOCATION_ID to identify the shipment, and returns the accumulated distribution quantity through an IN OUT NOCOPY parameter, a signature choice that avoids a copy of the numeric value on the call stack and reflects the package's origin in pre-11g PL/SQL coding practice. VAL_DISTRIBUTION_EXISTS is a BOOLEAN function that validates whether at least one distribution exists for a specified shipment, allowing calling code to branch on whether distribution data has already been created or must be defaulted. TEST_VAL_DISTRIBUTION_EXISTS is a companion test wrapper for that validation function, and TEST_GET_TOTAL_DIST_QTY performs the analogous role for the quantity procedure. These test entry points are diagnostic harnesses retained in the production package header, useful for ad hoc verification in a development or test instance. The remaining documented unit, VAL_APPROVAL_STATUS, provides validation related to approval status in the distribution context. The ETRM classifications occasionally render the package-level NAMES and NAME identifiers as procedure entries; these are artifacts of the extraction rather than callable business routines.

Tables Accessed

The only table documented for this package is PO_DISTRIBUTIONS, accessed through its APPS synonym. PO_DISTRIBUTIONS stores one row per distribution, keyed to the shipment through PO_LINE_LOCATION_ID, and holds the distributed quantity, destination and deliver-to information, project and task references, and accounting charge details. GET_TOTAL_DIST_QTY aggregates the distribution quantity column across the rows belonging to a shipment, and VAL_DISTRIBUTION_EXISTS probes the same table for the existence of any row for that shipment. The package performs no documented writes outside this table; its role is predominantly read-oriented for defaulting and validation purposes, while inserts and updates to distributions are performed by other purchasing distribution packages.

Usage Notes

PO_DIST_S is invoked from the Purchasing forms layer, where the distributions window calls GET_TOTAL_DIST_QTY to propose the undistributed quantity when a user adds a distribution to a shipment, and calls VAL_DISTRIBUTION_EXISTS to decide whether defaulting is required. Because the package is stored in APPS and relies on APPS synonyms, custom code should call it as APPS.PO_DIST_S rather than referencing a private schema. The ETRM metadata records the package as referenced by two other packages, confirming its role as a shared utility rather than a standalone entry point. Customizations that need the same defaulting arithmetic should call the packaged routines instead of querying PO_DISTRIBUTIONS directly, so that the standard aggregation logic and validation rules are reused consistently. The test wrappers can be invoked manually in non-production environments.