Search Results allocation_basis_code

Overview

INL_ALLOCATION_BASIS_VL is a language-enabled (VL) view owned by the APPS schema within the Oracle Landed Cost Management (INL) product family. Its documented purpose is to present Allocation Basis information in a given language, exposing the set of allocation bases available for distributing landed cost charges across receipt lines and inventory transactions.

In Landed Cost Management, an allocation basis determines how a charge (for example, freight, duty, or insurance) is apportioned across the goods being received. Typical bases include Quantity, Volume, Weight, Amount, and Value. The view is not backed by a dedicated transactional table; instead, the allocation basis codes are sourced from the PON_PE_ALLOCATION_BASIS lookup type, meaning the lookup framework serves as the master list of valid bases. This design allows Oracle and customers to extend or translate the available bases through standard lookup maintenance rather than through table changes.

Because it is a VL view, it resolves the user's session language automatically, returning lookup meanings appropriate to the current locale. The view is therefore a reporting and integration convenience object, used by forms, concurrent programs, and external interfaces that need a translated list of allocation bases without joining lookup and UOM tables directly.

Underlying Base Objects

The documented definition of the view references three base objects:

• FND_LOOKUP_VALUES_VL (VIEW) — supplies ALLOCATION_BASIS_CODE and ALLOCATION_BASIS_NAME from the lookup values where LOOKUP_TYPE = 'PON_PE_ALLOCATION_BASIS'.
• MTL_UNITS_OF_MEASURE (SYNONYM) — outer-joined to provide the unit of measure class and base unit of measure associated with each basis.
• FND_PROFILE (PACKAGE) — referenced for environment and language context, consistent with VL view behavior.

The join between lookup codes and UOM classes is driven by a DECODE: the code 'QUANTITY' maps to the QUANTITY class, 'VOLUME' to VOLUME, and 'WEIGHT' to WEIGHT. All other codes (for example, Amount or Value bases) produce no match and rely on the outer join. The UOM side is restricted to records where BASE_UOM_FLAG = 'Y', so each class contributes exactly its base unit — such as Each for QUANTITY, Liter or its class base for VOLUME, and Kilogram for WEIGHT.

Key Columns

• ALLOCATION_BASIS_ID — Hard-coded to -1. The view surfaces a synthetic key because allocation bases are not stored with surrogate identifiers; the underlying source is a lookup code.
• ALLOCATION_BASIS_CODE — The lookup code (for example, QUANTITY, VOLUME, WEIGHT, AMOUNT), which is the operative value stored on landed cost allocation records.
• ALLOCATION_BASIS_NAME — The translated meaning of the lookup code, suitable for display in forms and reports.
• UOM_CLASS — The unit of measure class (QUANTITY, VOLUME, WEIGHT) resolved for the basis, or null where the basis is monetary rather than physical.
• BASE_UOM_CODE — The base unit of measure for the resolved UOM class. This is the column returned when a user searches on "base_uom_code", and it identifies the unit in which the allocation would be measured for physical bases.

Common Use Cases and Queries

The view is most often consumed by Landed Cost Management setup and allocation logic, and by reports that validate which allocation bases are permitted. A basic query lists all available bases with their translation and associated physical unit:

• SELECT ALLOCATION_BASIS_CODE, ALLOCATION_BASIS_NAME, UOM_CLASS, BASE_UOM_CODE FROM APPS.INL_ALLOCATION_BASIS_VL ORDER BY ALLOCATION_BASIS_CODE;
• To isolate physical bases only: SELECT ALLOCATION_BASIS_CODE, BASE_UOM_CODE FROM APPS.INL_ALLOCATION_BASIS_VL WHERE UOM_CLASS IS NOT NULL;
• To confirm the unit that a weight- or volume-based allocation would resolve to, filter on the code directly: SELECT BASE_UOM_CODE FROM APPS.INL_ALLOCATION_BASIS_VL WHERE ALLOCATION_BASIS_CODE = 'WEIGHT';

These queries are useful during implementation to verify that base units of measure are correctly defined for each class, since a missing BASE_UOM_FLAG value in MTL_UNITS_OF_MEASURE would leave BASE_UOM_CODE null even though the basis exists. Integration scripts that build allocation records should read the code column, not the synthetic ID.