Results for “mtl_sales_orders”

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

Overview

MTL_SALES_ORDERS is an Inventory (INV) module table that stores local definitions of sales orders within Oracle E-Business Suite 12.1.1 and 12.2.2. Rather than acting as the master transactional repository for order management, this table functions as a lightweight local registry of sales order identifiers referenced by inventory, planning, and shop floor components. Its records are consumed by demand management, forecasting, reservations, scheduling, RMA processing, and work-in-process allocation logic.

From a Data Vault modeling perspective, the heuristic classification for MTL_SALES_ORDERS is hub-leaning. The table carries a single surrogate primary key, SALES_ORDER_ID (MTL_SALES_ORDERS_PK), and exposes no descriptive measures or transactional attributes beyond control flags and a key flexfield. It is therefore best treated as a hub entity around which multiple dependent link tables resolve demand-source references.

Key Information Stored

The documented physical schema in ETRM 12.2.2 defines 36 columns. The most significant are:

• SALES_ORDER_ID — surrogate primary key and the unique index candidate (MTL_SALES_ORDERS_U1). This is the value propagated into every dependent foreign key column across the EBS schema.
• SEGMENT1 through SEGMENT20 — a multi-segment key flexfield structure used to represent the sales order identifier in local, human-readable form.
• ENABLED_FLAG — indicates whether the local sales order definition is active for demand and allocation processing.
• SUMMARY_FLAG — identifies whether the record represents a summary-level entry.
• START_DATE_ACTIVE / END_DATE_ACTIVE — date-range bounds controlling the validity window of the definition.
• SOURCE_CODE — identifies the originating source of the record.
• ORDER_TYPE — classifies the sales order for downstream processing rules.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program audit columns identifying the process that created or last updated the row.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard EBS who-columns for audit and change tracking.

The surrogate key SALES_ORDER_ID should not be conflated with the concatenated SEGMENT flexfield values, which serve as the business-key representation.

Common Use Cases and Queries

The primary use case is resolving demand-source references. A typical query joins WIP_SO_ALLOCATIONS to MTL_SALES_ORDERS to identify which sales order a shop floor allocation is consuming against:

• Reporting allocations by sales order: SELECT w.DEMAND_SOURCE_HEADER_ID, s.SEGMENT1 FROM WIP_SO_ALLOCATIONS w JOIN MTL_SALES_ORDERS s ON w.DEMAND_SOURCE_HEADER_ID = s.SALES_ORDER_ID;
• Auditing demand records in MTL_DEMAND against their header definition using DEMAND_SOURCE_HEADER_ID.
• Validating forecast update processing through MRP_FORECAST_UPDATES.UPDATE_SALES_ORDER.
• Checking active definitions with a predicate on ENABLED_FLAG and the START_DATE_ACTIVE / END_DATE_ACTIVE window.

Related Objects

The following tables reference MTL_SALES_ORDERS through documented foreign keys:

• WIP_SO_ALLOCATIONS — via DEMAND_SOURCE_HEADER_ID; the direct answer to the wip_so_allocations search.
• MTL_DEMAND — via DEMAND_SOURCE_HEADER_ID, linking demand rows to their source header.
• MTL_DEMAND_INTERFACE — via DEMAND_SOURCE_HEADER_ID, for inbound demand loading.
• MRP_RESERVATIONS — via DISPOSITION_ID.
• MRP_SCHEDULE_DATES — via SOURCE_SALES_ORDER_ID.
• MRP_FORECAST_UPDATES — via UPDATE_SALES_ORDER.
• MTL_SO_RMA_INTERFACE — via SALES_ORDER_ID, for return material authorization staging.

Because every relationship is oriented outward from MTL_SALES_ORDERS, the table behaves as a reference hub rather than a transaction fact, and joins should always resolve to the surrogate SALES_ORDER_ID.