Results for “allocation_uom_code”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

INL_ADJ_ASSOCIATIONS_V is a VALID dictionary view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the INL – Oracle Landed Cost Management product. It exposes adjusted associations between landed cost components that may belong to the same shipment or to different shipments, making it the reporting-facing representation of the association and adjustment data stored in INL_ASSOCIATIONS.

The view does not merely pass through the base association rows. Its distinguishing behavior is that it resolves hierarchical parent identifiers to their leaf values. Charge lines, tax lines, and shipment lines in Landed Cost Management can be organized in parent-child relationships; adjustments are frequently posted against a parent record, while reporting and downstream integration require the terminal (leaf) identifier. INL_ADJ_ASSOCIATIONS_V performs that resolution at query time using hierarchical (CONNECT BY) subqueries combined with CONNECT_BY_ISLEAF and MAX. The result is a flattened, reporting-ready projection in which every FROM and TO identifier points to an actual leaf-level cost component rather than an intermediate parent.

Because the definition is delivered and maintained by Oracle, the view provides a supported, upgrade-safe access path. Customers can join it to shipment and cost component tables for reconciliation, landed cost analysis, allocation audits, and integration extracts without writing custom recursive SQL. Its scope is limited to landed cost association and adjustment data; it is not a general-purpose inventory valuation or costing view.

Underlying Base Objects

The documented base objects referenced by the view are INL_ASSOCIATIONS, INL_CHARGE_LINES, INL_SHIP_LINES_ALL, and INL_TAX_LINES, all accessed through APPS synonyms. INL_ASSOCIATIONS is the driving table, aliased as A, and provides the association identifier, shipment header, parent table names and identifiers, allocation attributes, and the adjustment type flag. The remaining three objects are referenced inside scalar DECODE subqueries and are used to descend each hierarchy to its leaf: INL_SHIP_LINES_ALL for shipment line parents, INL_CHARGE_LINES for charge line parents, and INL_TAX_LINES for tax line parents.

The DECODE logic on FROM_PARENT_TABLE_NAME and TO_PARENT_TABLE_NAME dispatches resolution to the appropriate base object based on the recorded parent table name. Where the parent table name is not one of the recognized values, the original identifier is returned unchanged. A significant consequence of this design is that the view is not a simple single-table projection: it fires correlated hierarchical subqueries for the parent identifiers, so query cost depends heavily on indexing of the parent identifier columns and on the depth of the line hierarchies.

Key Columns

• ASSOCIATION_ID — Surrogate identifier of the underlying INL_ASSOCIATIONS row.
• SHIP_HEADER_ID — Shipment header associated with the record, enabling shipment-level reporting and joins.
• FROM_PARENT_TABLE_NAME — Name of the base table from which the association originates (for example, INL_SHIP_LINES, INL_CHARGE_LINES, or INL_TAX_LINES).
• FROM_PARENT_TABLE_ID — Source identifier, resolved to the leaf record by the DECODE logic.
• TO_PARENT_TABLE_NAME — Name of the base table that receives the association.
• TO_PARENT_TABLE_ID — Target identifier, likewise resolved to its leaf.
• ALLOCATION_BASIS — Basis on which landed cost is allocated across the association.
• ALLOCATION_UOM_CODE — Unit of measure applied to the allocation basis.
• ADJUSTMENT_TYPE_FLAG — Indicator of the adjustment type represented by the row.

Common Use Cases and Queries

Typical scenarios include reviewing which cost components an adjustment touched, tracing a shipment's adjusted associations, and feeding landed cost analysis or integration extracts.

• List adjustments by shipment:

  SELECT association_id, ship_header_id, adjustment_type_flag,
         from_parent_table_name, from_parent_table_id,
         to_parent_table_name, to_parent_table_id
  FROM   apps.inl_adj_associations_v
  WHERE  ship_header_id = :p_ship_header_id;

• Isolate charge and tax adjustments:

  SELECT association_id, from_parent_table_name, to_parent_table_name,
         allocation_basis, allocation_uom_code, adjustment_type_flag
  FROM   apps.inl_adj_associations_v
  WHERE  adjustment_type_flag IS NOT NULL
  ORDER  BY ship_header_id, association_id;

• Reconcile against the base table:

  SELECT v.association_id, a.from_parent_table_id AS raw_from_id,
         v.from_parent_table_id AS leaf_from_id
  FROM   apps.inl_adj_associations_v v,
         apps.inl_associations a
  WHERE  v.association_id = a.association_id;

Because the view resolves hierarchy. Bear in mind the row count is governed by INL_ASSOCIATIONS, and filtering on ship_header_id or association_id before joining to large cost tables minimizes hierarchical evaluation. For high-volume extracts, an explicit join to the underlying objects may outperform the view when leaf resolution is unnecessary.