Search Results get_receiveamount




Overview
Explore in AI Chat

Overview

RCV_INVOICE_MATCHING_SV is a server-side PL/SQL package body owned by APPS in Oracle E-Business Suite. Its header identifies a revision of RCVITRMB.pls, with the last change recorded in 2011 under the 12.1.1 code line; the object remains present in 12.2.2 with the same documented API surface. The package supports receiving-to-payables invoice matching, the process by which quantities recorded against purchase order shipments are compared with quantities billed by suppliers. It resolves the quantities held at the purchase order, shipment or line location, and receiving transaction levels so that Payables can determine whether an invoice line may be validated, placed on hold, or matched within tolerance.

ETRM classifies the package as API classification OTHER, meaning it is not a formally published open interface but an internal service that other Oracle Receiving components call. The metadata records four documented program units: NAMES, NAME, GET_RECEIVEAMOUNT, and GET_DELIVERAMOUNT. The body excerpt supplied for this object, however, shows the signature of GET_QUANTITIES, which resolves ordered, cancelled, received, corrected, delivered, RTV, billed, accepted, and rejected quantities in both primary and transaction units of measure. This indicates the package groups several related quantity-derivation routines, with GET_RECEIVEAMOUNT and GET_DELIVERAMOUNT forming the core of the matching calculation.

Key Procedures and Functions

The documented program units serve the following purposes:

  • GET_RECEIVEAMOUNT — Derives the amount or quantity eligible for matching at the receiving stage for a given transaction or shipment, drawing on receipt and delivery information recorded against the associated purchase order. It is the procedure referenced by the search term "get_receiveamount" and is the primary entry point for callers that need the received-side figure used in invoice matching.
  • GET_DELIVERAMOUNT — Resolves the delivered position, that is, the quantity or value that has physically moved to the destination or final delivery location and therefore may be billed. It complements GET_RECEIVEAMOUNT by distinguishing receipts held at the receiving dock from goods actually delivered.
  • NAME — A single-entity lookup returning the name associated with a supplied identifier, used to translate internal keys into display or descriptive values for the callers of the package.
  • NAMES — The plural counterpart of NAME, resolving names for a set of identifiers, typically invoked where a caller must label multiple records in one pass.

No parameter lists are asserted here beyond those documented; callers should obtain the exact signature from the package specification in the target release.

Tables Accessed

The package reads and, where required, writes through APPS synonyms on the following documented tables:

  • RCV_SHIPMENT_LINES — Supplies the shipment-level receiving quantities that anchor the amount calculations.
  • RCV_TRANSACTIONS — Provides the individual receipt, delivery, correction, return-to-vendor, accept, and reject transactions that are aggregated to produce the matching quantities.
  • PO_LINE_LOCATIONS — Contributes the purchase order shipment and distribution scheduling attributes needed to relate receiving activity back to the ordered quantity and to the correct unit of measure.
  • PO_DISTRIBUTIONS — Used to associate matched quantities with the accounting distributions against which invoice matching and accrual are performed.

Usage Notes

RCV_INVOICE_MATCHING_SV is invoked internally by Oracle Receiving and Payables flows and is referenced by seven other packages in the APPS schema, confirming its role as a shared service rather than a standalone interface. It is typically called from receipt and matching forms, from the invoice validation path when a purchase order matched invoice line is processed, and from correction or delivery routines that must recompute the receivable or deliverable position. Because the routines perform no user-facing validation and no commit, custom code may call them to obtain quantity or amount figures, but any resulting DML must be committed by the caller. Recompilation of the package invalidates dependent packages, so it should be recompiled during planned maintenance windows and its dependents revalidated afterward.