Search Results process_charges

Overview

APPS.RCV_CHARGES_GRP is a group-type PL/SQL package in Oracle E-Business Suite Receiving that manages the lifecycle of charges associated with inbound receipt transactions. It provides the application programming interface layer through which charge information captured at the receipt level is derived, validated, persisted, and allocated across receipt headers and lines. In the context of Oracle EBS 12.1.1 and 12.2.2, this package is a foundational component of the Receiving Open Interface (ROI) processing architecture, working alongside preprocessor and processor packages to transform interface staging records into finalized charge records used by purchasing and receiving accounting.

The package is classified as a GRP API, meaning it is intended for internal orchestration and processing logic rather than direct external invocation by customer extensions. Its responsibilities span three distinct phases: deriving and defaulting charge data into the interface table, populating the permanent charge tables from validated interface data, and distributing header-level and line-level charges across receipt lines. The header comment block confirms the initial version 1.0 designation, indicating an established, stable API that has been part of the receiving charge framework across multiple releases.

Key Procedures and Functions

• Preprocess_Charges — Derives, defaults, and validates data in the charge interface table for each item transaction interface record. This procedure constitutes the first stage of the charge pipeline and ensures that incoming interface rows carry the correct default and derived values before persistence. It returns standard API status, message count, and message data outputs along with the API version and initialization flag inputs, and it operates against header and transaction record cursor types sourced from the receiving preprocessor logic.
• Process_Charges — Populates the charge tables with the interface data. This procedure consumes the validated charge interface rows and writes them into the permanent purchasing receipt charge structures. It accepts header interface, transaction interface, shipment header, and shipment line identifiers to anchor the charge records to the correct receipt context.
• Allocate_Charges — Allocates header-level and line-level charges across the applicable receipt structure. This procedure receives and returns a charge table collection typed from the PO_CHARGES_GRP package, along with a charge allocation table, enabling the distribution of aggregated charges to individual lines.

All three procedures follow the Oracle EBS API convention of returning x_return_status, x_msg_count, and x_msg_data to communicate execution outcomes.

Tables Accessed

The package references a defined set of tables through APPS synonyms. On the receiving side it reads and writes RCV_CHARGES_INTERFACE, the staging table for charge data, and RCV_HEADERS_INTERFACE and RCV_TRANSACTIONS_INTERFACE, which provide the receipt header and line context for ROI processing. It reads RCV_SHIPMENT_HEADERS and RCV_SHIPMENT_LINES to associate charges with specific shipments.

Master data lookups include MTL_SYSTEM_ITEMS for item validation and the MTL_UNITS_OF_MEASURE, MTL_UNITS_OF_MEASURE_TL, and MTL_UOM_CLASSES tables for unit of measure verification. Purchasing tables PO_LINES_ALL and PO_RCV_CHARGES, PO_RCV_CHARGES_S, PO_RCV_CHARGE_ALLOCATIONS, and PO_RCV_CHARGE_ALLOCATIONS_S provide the destination structures for persisted charge and allocation records. DBMS_UTILITY is used for standard Oracle utility operations such as error stack retrieval.

Usage Notes

RCV_CHARGES_GRP is typically invoked indirectly rather than called directly by end users or forms. It is driven by the Receiving Open Interface processing flow and related concurrent programs that submit receipt transactions for validation and import. Because it is referenced by two other packages, it functions as a subordinate processing component within the broader receiving charge framework.

Custom development and integration code should generally interact with the higher-level ROI submission APIs rather than calling this group package directly, since the GRP classification signals that internal call sequencing, dependencies, and record expectations are managed by Oracle's orchestration logic. Developers extending receipt charge functionality should treat this package as the authoritative implementation of charge preprocessing, persistence, and allocation when diagnosing charge-related receipt import failures or when tracing how courier and freight charge notes flow from interface staging into the PO_RCV_CHARGES structures.