Search Results charge_allocation_id




Overview
Explore in AI Chat

Overview

APPS.INL_PO_CHARGE_ALLOCATIONS_V is a consolidated reporting view that exposes landed cost and charge allocation data associated with purchase order receipt shipments in Oracle E-Business Suite. Its principal role is to unify two semantically equivalent data sources — the current landed cost allocations held by Oracle Landed Cost Management (INL) and the historical or freight-related allocations persisted in PO_RCV_CHARGE_ALLOCATIONS — into a single, stable column set. This makes the view suitable for reporting, reconciliation, and integration scenarios where consumers require a consistent representation of estimated versus actual charge amounts per shipment line and per charge line.

The view is particularly relevant to users reconciling landed cost accruals against actual invoices, since it exposes both the estimated allocation and a dynamically computed actual amount. Because the actual amounts are derived at query time through packaged PL/SQL functions rather than being stored, the view reflects current calculations each time it is queried.

Underlying Base Objects

The view is defined over the following documented base objects:

  • INL_ALLOCATIONS — the primary driver of the first UNION ALL branch, filtered to landed cost rows (landed_cost_flag = 'Y') with adjustment_num = 0.
  • INL_CHARGE_LINES — supplies the charge line identity and charge line type.
  • PO_LINE_LOCATIONS_ALL — joined via RCV_SHIPMENT_LINES.po_line_location_id to retrieve the original unit price from price_override.
  • RCV_SHIPMENT_LINES — links ship lines to their originating PO line locations.
  • INL_SHIPMENT_PVT — an API package invoked for charge amount and tax amount computation.
  • PO_RCV_CHARGE_ALLOCATIONS — the second UNION ALL branch, providing previously stored charge allocation rows.

The two branches are combined with UNION ALL, yielding the same fifteen-column projection. The first branch computes values from live INL and PO sourcing data; the second simply projects columns already present in PO_RCV_CHARGE_ALLOCATIONS.

Key Columns

  • charge_allocation_id — the allocation identifier (INL allocation_id or the equivalent stored column).
  • charge_id — the charge line identifier.
  • shipment_line_id — the receipt shipment line the allocation applies to.
  • estimated_amount — the estimated charge allocation; sourced from INL_ALLOCATIONS.allocation_amt in the first branch.
  • actual_amount — computed via INL_SHIPMENT_PVT.Get_MatchedAmt against INL_CHARGE_LINES.
  • original_unit_price — the price_override value from PO_LINE_LOCATIONS_ALL. This is the column most frequently referenced by users searching for unit price context, and it reflects the overridden unit price of the associated PO line location rather than a base catalog price.
  • original_unit_nr_tax, est_recoverable_tax, est_non_recoverable_tax, act_recoverable_tax — tax breakdown columns; the first three are hard-coded to 0 in the computed branch.
  • act_non_recoverable_tax — dynamically retrieved through Get_MatchedAmt against INL_TAX_LINES.
  • Audit columns — creation_date, created_by, last_update_date, last_updated_by.

Common Use Cases and Queries

Typical uses include reconciling estimated landed cost against actual matched charges, auditing unit price overrides applied to landed cost lines, and feeding downstream cost analysis without needing to understand the INL or OPM allocation internals. A representative query retrieving original unit price alongside estimated and actual charges would be:

  • SELECT shipment_line_id, charge_id, original_unit_price, estimated_amount, actual_amount FROM apps.inl_po_charge_allocations_v WHERE shipment_line_id = :p_shipment_line_id;
  • SELECT charge_allocation_id, SUM(actual_amount) FROM apps.inl_po_charge_allocations_v GROUP BY charge_allocation_id;
  • SELECT v.* FROM apps.inl_po_charge_allocations_v v, rcv_shipment_lines rsl WHERE v.shipment_line_id = rsl.shipment_line_id AND rsl.shipment_header_id = :p_header_id;

Because actual amounts and non-recoverable tax are evaluated through PL/SQL on each execution, queries against this view may incur additional processing overhead relative to querying a stored table directly.