Search Results mtl_pick_slip_numbers




Overview

MTL_PICK_SLIP_NUMBERS is an Inventory (INV) module table in the Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. Per ETRM documentation, the table is used by parallel pick release to coordinate and track the generation of pick slip numbers when the pick release process runs concurrently. The object is owned by the INV schema, is classified with a status of VALID, and is documented with six physical columns in the 12.2.2 schema.

Pick release converts eligible sales order or transfer order demand into move order lines that warehouse personnel execute for outbound shipment. When the workload is processed in parallel, each concurrent worker stream must draw its own unique pick slip identifiers without collision. MTL_PICK_SLIP_NUMBERS provides the bookkeeping layer that assigns and tracks those identifiers, maintaining a count of pick slips generated per batch so that the parallel program does not duplicate numbers across streams.

Under the heuristic Data Vault classification mined from foreign key structure, the object is treated as standalone — it carries its own primary key and does not participate in documented hub or link relationships. From a modeling perspective, the table is best characterized as a satellite-style control or counter record, keyed by its own identifier and scoped to a pick release batch, rather than as a business hub or link entity.

Key Information Stored

The documented physical schema contains six columns. The most significant are:

  • ID — the single-column surrogate primary key for the row, used internally to uniquely identify each pick slip number record.
  • PICK_SLIP_IDENTIFIER — the business-level identifier for a pick slip. Together with STATUS it forms the documented unique index MTL_PICK_SLIP_NUMBERS_U1, making it the strongest business-key candidate in the table.
  • STATUS — the state of the pick slip number record; also part of the unique index with PICK_SLIP_IDENTIFIER. It allows the same identifier to be tracked across lifecycle stages without violating uniqueness within a given status.
  • PICK_SLIP_NUMBER — the actual pick slip number value assigned to a generated pick slip, which is the human-readable and printable reference used on the warehouse document.
  • PICK_SLIP_BATCH_ID — the identifier of the pick release batch to which the number belongs, correlating the record with a specific run or grouping of the pick release concurrent program.
  • PICK_SLIP_COUNT — the running count of pick slips generated, used by the parallel pick release process to allocate numbers and prevent gaps or duplication across concurrent workers.

The combination of ID (technical key) and PICK_SLIP_IDENTIFIER with STATUS (business key) is the primary distinction to observe when writing joins or de-duplication logic.

Common Use Cases and Queries

Practical uses center on auditing, troubleshooting, and reconciliation of pick release output. Typical scenarios include verifying that a parallel pick release run produced the expected number of pick slip numbers, diagnosing duplicate or skipped identifiers, and reporting pick slip volume by batch.

  • Listing all pick slip numbers for a batch: SELECT PICK_SLIP_NUMBER, PICK_SLIP_IDENTIFIER, STATUS FROM MTL_PICK_SLIP_NUMBERS WHERE PICK_SLIP_BATCH_ID = :batch_id;
  • Checking for duplicate business keys: SELECT PICK_SLIP_IDENTIFIER, STATUS, COUNT(*) FROM MTL_PICK_SLIP_NUMBERS GROUP BY PICK_SLIP_IDENTIFIER, STATUS HAVING COUNT(*) > 1;
  • Monitoring total counts generated per batch for performance or throughput analysis: SELECT PICK_SLIP_BATCH_ID, MAX(PICK_SLIP_COUNT) FROM MTL_PICK_SLIP_NUMBERS GROUP BY PICK_SLIP_BATCH_ID;
  • Filtering by lifecycle state to find incomplete allocations: SELECT * FROM MTL_PICK_SLIP_NUMBERS WHERE STATUS = :status;

These queries support operational reporting and are useful when the pick release concurrent program requires restart or when investigating downstream move order discrepancies.

Related Objects

The ETRM metadata classifies this object as standalone with no documented foreign key dependencies. Related tables are therefore identified by functional correlation rather than declared constraints:

Because the object is standalone, joins should be driven by batch identifier or pick slip identifier rather than by documented referential integrity.