Search Results rcv_charges_grp




Overview
Explore in AI Chat

Overview

PO_CHARGES_GRP is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified as a group (GRP) package. It provides the core charge-capture and charge-processing infrastructure used by Oracle Purchasing, Oracle Receiving, and Oracle Payables to reconcile the various charge types that can be attached to a procurement transaction. Its central purpose is to collect charges originating from different sources — supplier quotations, freight and other estimated landed-cost charges entered in Purchasing or Receiving, and the actual invoice distributions booked in Payables — and to persist them against the appropriate purchasing, receiving, and charge-allocation tables.

The package therefore acts as the shared engine behind charge comparison and accrual reporting in the Procure-to-Pay flow, enabling buyers and cost accountants to compare estimated charges against actual invoiced amounts. The package is documented as VALID and exposes public procedures that are callable from other Oracle packages as well as from custom extensions.

Key Procedures and Functions

  • CAPTURE_QP_CHARGES — Captures charges sourced from the Oracle Quoting / supplier quotation stream, writing them into the purchasing charge structures so that they are available for downstream comparison and allocation.
  • CAPTURE_FTE_ESTIMATED_CHARGES — Records the estimated freight and other landed-cost charges associated with a purchasing document, establishing the baseline figure against which actual charges will later be compared.
  • CAPTURE_FTE_ACTUAL_CHARGES — Records the actual charges as determined by receiving and invoicing activity, completing the estimated-versus-actual picture for landed-cost analysis.
  • EXTRACT_AP_ACTUAL_CHARGES — Reads Payables invoice lines and distributions to identify the true invoiced charge amounts that correspond to a procurement transaction, isolating them for matching.
  • PROCESS_AP_ACTUAL_CHARGES — Applies the extracted Payables charge information, updating the purchasing and receiving charge records to reflect the actual invoiced values.

No documented parameter lists are published in the ETRM metadata; callers should inspect the package specification in the target instance for exact signatures.

Tables Accessed

The package reads and writes a broad cross-section of Procure-to-Pay tables through APPS synonyms. On the Payables side it references AP_INVOICES_ALL, AP_INVOICE_LINES_ALL, and AP_INVOICE_DISTRIBUTIONS_ALL, which supply the actual invoiced charge amounts. On the purchasing side it touches PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, PO_DISTRIBUTIONS_ALL, PO_RCV_CHARGES, PO_RCV_CHARGES_S, PO_RCV_CHARGE_ALLOCATIONS, and PO_RCV_CHARGE_ALLOCATIONS_S — the sequence-numbered (_S) tables indicating that surrogate key generation is performed as part of record creation. On the receiving side it references RCV_TRANSACTIONS, RCV_SHIPMENT_LINES, RCV_HEADERS_INTERFACE, and RCV_PARAMETERS, linking charges to the physical receipt that generated them. Together these accesses support both the capture of estimated charges at ordering/receiving time and the reconciliation of those estimates to the actual Payables distributions.

Usage Notes

PO_CHARGES_GRP is normally invoked indirectly by Oracle Application modules rather than by end users directly. It is referenced by two other packages, including RCV_CHARGES_GRP and FTE_FPA_UTIL, which call into it during receiving and landed-cost processing. In practice the package is exercised when receipts are entered in the Receiving forms, when invoices are matched in Payables, and during the concurrent programs that reconcile estimated and actual charges. Custom code requiring charge capture or AP-actual extraction should call the public procedures rather than manipulating the underlying tables directly. Because the package writes to the charge and allocation tables, any custom invocation should be performed within a controlled transaction and followed by a commit, and the package specification should be reviewed in the specific 12.1.1 or 12.2.2 instance to confirm the current call signatures.