Search Results maximum_quantity




Overview

MTL_SECONDARY_LOCATORS_ALL_V is a view in the APPS schema belonging to the Oracle Inventory (INV) product. According to the ETRM metadata, its description is marked "10SC ONLY," indicating the object is scoped to specific Oracle application configurations rather than being a general-purpose inventory view. The view exposes secondary locator definitions for inventory items, combining locator-level attributes with descriptive information drawn from the item locations table.

Secondary locators are used in warehouse management scenarios where an item can be stored at more than one location within the same subinventory. The view therefore serves as a reporting and integration surface for teams that need to query which secondary locators exist for a given item and organization, along with the ordering and quantity constraints associated with each locator. Because it is a view rather than a table, it presents no independent storage; all data originates from the underlying locator tables.

Underlying Base Objects

The view is defined over two documented base objects, both referenced through synonyms:

  • MTL_SECONDARY_LOCATORS — the primary source of secondary locator records, contributing item, organization, locator identifier, primary locator flag, picking order, subinventory, and maximum quantity data.
  • MTL_ITEM_LOCATIONS — joined to supply the locator description.

The join is an outer join on the location table. The view text joins S.SECONDARY_LOCATOR = L.INVENTORY_LOCATION_ID (+) and S.ORGANIZATION_ID = L.ORGANIZATION_ID. The outer-join syntax on INVENTORY_LOCATION_ID means secondary locator rows are retained even when no matching item location record exists, in which case DESCRIPTION is null. Because the join also constrains on organization, descriptions are resolved only for locators belonging to the same organization as the secondary locator record. The view text also selects S.ROWID, exposing the row identifier of the underlying MTL_SECONDARY_LOCATORS row rather than a row identifier from the joined table.

Key Columns

  • ROW_ID — the ROWID of the underlying secondary locator row.
  • INVENTORY_ITEM_ID — identifier of the inventory item the secondary locator applies to.
  • ORGANIZATION_ID — the inventory organization that owns the locator definition.
  • SECONDARY_LOCATOR — the locator identifier, joined to INVENTORY_LOCATION_ID in MTL_ITEM_LOCATIONS.
  • DESCRIPTION — the locator description obtained from MTL_ITEM_LOCATIONS; may be null when no matching location exists.
  • PRIMARY_LOCATOR_FLAG — indicates whether the record designates the primary locator.
  • PICKING_ORDER — the sequence used when picking from multiple locators.
  • SUBINVENTORY_CODE — the subinventory in which the secondary locator resides.
  • MAXIMUM_QUANTITY — the maximum quantity permitted for the secondary locator; this is the column most commonly searched for in this view.
  • Audit columnsLAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical usage includes reviewing maximum quantity thresholds per item and locator, confirming picking order across secondary locators, and producing item-to-locator reports for a given organization. A representative query listing all secondary locators for an item, including maximum quantity, is:

  • SELECT inventory_item_id, organization_id, secondary_locator, subinventory_code, maximum_quantity, picking_order, primary_locator_flag, description FROM mtl_secondary_locators_all_v WHERE organization_id = :org_id AND inventory_item_id = :item_id ORDER BY picking_order;
  • To isolate locators with a defined maximum quantity: SELECT * FROM mtl_secondary_locators_all_v WHERE maximum_quantity IS NOT NULL;
  • To find records lacking a matched location description: SELECT * FROM mtl_secondary_locators_all_v WHERE description IS NULL;

Because the object is documented as "10SC ONLY," availability and behavior may be restricted to specific configurations, and validation against the target environment is advisable before relying on it in custom integrations.