Search Results mtl_transaction_lots_temp




Overview
Explore in AI Chat

Overview

MTL_TRANSACTION_LOTS_TEMP is a transient staging table owned by the INV schema in Oracle EBS 12.1.1 and 12.2.2. Its documented description is a "temporary lot numbers holding table." As the name implies, it serves as an intermediate work area in which lot-level details are assembled before the transaction processing engine validates and commits them into the permanent inventory lot and transaction tables. Columns such as REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID and PROGRAM_UPDATE_DATE confirm its role as a concurrent-program scratch area: rows are written under a specific request context, processed, and then either purged or persisted to their target destinations.

The table carries the full lifecycle attributes of a lot — expiration dates, supplier data, grade codes, and a large flexible-attribute block — allowing the application to perform validation, defaulting, and attribute derivation before the transaction is finally applied. Because it holds uncommitted or in-flight data rather than durable master data, the heuristic Data Vault classification supplied in the metadata is standalone; in a modeling exercise this would typically be treated as a transient staging/secondary satellite rather than a conformed hub or link.

Key Information Stored

The table exposes 165 documented columns, reflecting the breadth of lot attributes that must be validated prior to commit. The most significant include:

Common Use Cases and Queries

This table is principally of interest to technical consultants diagnosing transaction failures, reviewing defaults applied during receipt or issue processing, and building reconciliations between staged and committed lot data. Typical patterns include:

  • Retrieving all staged lots for a given concurrent request: SELECT * FROM mtl_transaction_lots_temp WHERE request_id = :request_id;
  • Identifying error rows within a batch: SELECT transaction_temp_id, lot_number, error_code FROM mtl_transaction_lots_temp WHERE error_code IS NOT NULL;
  • Joining staged lots back to their source product transaction to confirm traceability: ... FROM mtl_transaction_lots_temp t JOIN csd_product_transactions p ON t.product_transaction_id = p.product_transaction_id;
  • Tracing lots approaching expiry for review: filtering on LOT_EXPIRATION_DATE, RETEST_DATE, or EXPIRATION_ACTION_DATE.

Because rows are transient, reporting queries should generally be time-bounded and scoped by REQUEST_ID or program context rather than used for persistent lot reporting.

Related Objects