Search Results get_net_qty

Overview

ICX_PO_RCV_QTY is a small utility package body owned by the APPS schema in Oracle E-Business Suite. It was originally delivered as part of the iProcurement / Internet Commerce Exchange (ICX) product family, as indicated by the ICX prefix and the header reference to ICXRCQTB.pls. Its sole purpose is to derive the net received quantity of a purchasing or receiving transaction by adjusting a supplied primary quantity for any subsequent correction transactions that reference the same parent transaction.

In Oracle EBS receiving, a receiving transaction can be corrected after the fact. A correction does not overwrite the original row in the receiving transaction table; instead it creates an additional transaction of type 'CORRECT' that is linked to the original through the parent_transaction_id column. The original primary quantity therefore no longer reflects the true quantity actually received. The business function of this package is to reconcile that difference programmatically, so that downstream ICX pages — order status, receipt confirmation, and related self-service displays — show the correct net quantity rather than the raw stored value.

Key Procedures and Functions

The package exposes a single documented function, GET_NET_QTY. Although the public signature is not reproduced here per documentation conventions, its behavior is defined by the delivered source: it accepts a parent transaction identifier and a primary quantity, sums the primary_quantity of all correction transactions belonging to that parent, and returns the arithmetic difference between the supplied quantity and the summed corrections.

• GET_NET_QTY — Returns a NUMBER representing the net quantity after corrections. It takes the parent transaction identifier used to locate child correction rows and the primary (original) quantity to be adjusted. Internally it uses NVL(SUM(...), 0) so that transactions with no corrections return the original quantity unchanged rather than NULL.
• Package-level design — The package body contains no global variables, no initialization section, and no overloaded handlers. It is a pure, stateless calculation helper, which makes it safe to call repeatedly within loops and from SQL contexts.

Tables Accessed

The package reads from a single table, RCV_TRANSACTIONS, accessed through the APPS synonym layer. The query filters on two columns:

• PARENT_TRANSACTION_ID — Restricts the aggregation to correction rows whose parent is the transaction supplied by the caller.
• TRANSACTION_TYPE — Restricted to the literal value 'CORRECT', ensuring that only correction records reduce the net quantity and that ordinary receipts, deliveries, and returns handled elsewhere are excluded.
• PRIMARY_QUANTITY — Aggregated with SUM and wrapped in NVL to guarantee a numeric result.

The package performs no inserts, updates, or deletes. It is strictly read-only with respect to the database and writes nothing to RCV_TRANSACTIONS or any other object.

Usage Notes

Because the package is classified as OTHER and is not a public committed API, it is an internal helper rather than a supported extension point. ETRM records four other packages that reference it, indicating that it is called from sibling ICX receiving logic — most likely the PL/SQL used by iProcurement receipt and order-status pages — where quantities must be displayed net of corrections.

Typical invocation occurs from custom code or reports that need to mirror the same net-quantity calculation as the standard ICX pages. A developer would query the original receiving transaction to obtain its primary quantity and transaction identifier, pass both to GET_NET_QTY, and use the returned value for display or comparison. It is rarely, if ever, called from a concurrent program directly, as it performs no bulk processing and has no concurrent-manager entry point.

Two practical cautions apply. Since correction rows are matched solely by parent_transaction_id and transaction_type, callers must pass a transaction that is genuinely the parent of the corrections in question; passing a child correction row's identifier will return an unadjusted quantity. The same holds true in Oracle EBS 12.1.1 and 12.2.2, where the delivered logic and table structure remain unchanged. All correction handling should be validated against the standard receiving screens before the result is relied upon in a custom process.