Search Results mtl_sub_ast_val_v




Overview

MTL_SUB_AST_VAL_V is a read-only view owned by the APPS schema in Oracle E-Business Suite, registered under the Inventory (INV) product module. Its name — Material Subinventory Asset Value — indicates its purpose: to expose the subset of subinventories that are defined as asset subinventories and are currently active. The view is documented in ETRM with the note "Retrofitted," indicating that it was carried forward or re-created to support existing functionality during an upgrade cycle, and it retains validity in both 12.1.1 and 12.2.2.

Rather than storing data, the view presents a filtered projection of the MTL_SECONDARY_INVENTORIES table. This makes it a convenient reporting and integration surface: external systems, custom concurrent programs, and Oracle Application Framework extensions can query a single object and be assured that only asset-tracked, non-disabled subinventories are returned. It is commonly referenced where valuation, costing, or asset-related logic must be restricted to subinventories that carry asset value.

Underlying Base Objects

The view is defined over a single base object: MTL_SECONDARY_INVENTORIES, referenced in the APPS schema through a SYNONYM. MTL_SECONDARY_INVENTORIES is the core Inventory table that stores subinventory definitions per organization, including accounting defaults, picking rules, and status flags. No joins to other tables are present in the documented view text, so the view does not aggregate inventory balances, item locations, or on-hand quantities. Its relationship to the base table is therefore one of restriction and projection: it selects a defined column list and applies three filter predicates.

The WHERE clause requires that the DISABLE_DATE be null or in the future (NVL(DISABLE_DATE, SYSDATE+1) > SYSDATE), that ASSET_INVENTORY equal 1, and that SUBINVENTORY_TYPE be 1 or null. In effect, the view returns active subinventories whose contents are treated as assets.

Key Columns

Common Use Cases and Queries

Typical use cases include validating that a chosen subinventory is asset-tracked before posting valuation entries, driving reports of asset subinventories with their accounting defaults, and populating LOVs in custom forms or OAF pages. Because the view already enforces the asset and active filters, callers avoid re-implementing that logic. A representative query is:

SELECT organization_id, secondary_inventory_name, material_account, material_overhead_account
FROM apps.mtl_sub_ast_val_v
WHERE organization_id = :org_id
ORDER BY secondary_inventory_name;

Another common pattern joins the view to organization or accounting lookups:

SELECT v.secondary_inventory_name, v.asset_inventory, v.material_account
FROM apps.mtl_sub_ast_val_v v
WHERE v.inventory_atp_code = 1;

In integration scenarios the view is often the source for extract programs that feed costing or fixed-asset interfaces, ensuring only asset subinventories are transmitted. Since it performs no joins and only simple predicates on MTL_SECONDARY_INVENTORIES, performance is generally governed by indexes on the base table, and users should still filter by ORGANIZATION_ID where a single organization is intended.