Search Results valid_lot_number

Overview

WSH_DEL_OI_CORE is the core validation package used by the Oracle Shipping Execution open interface (delivery open interface) in Oracle E-Business Suite Release 12.1.1 and 12.2.2. Its stated purpose, taken from the package header comments, is to provide "Core Validation Routines for Open Interface." The package is owned by APPS and is classified as an OTHER API rather than a formally published public API, meaning it is intended for internal consumption by shipping open interface processing logic rather than for direct customer invocation. It is declared with AUTHID CURRENT_USER and was originally created in May 1996 (header revision 115.5), so it represents a long-standing, stable component of the shipping validation layer.

The routines in this package centralize the domain validation and defaulting logic required before delivery interface records can be processed: verifying that a carrier, freight type, currency, unit of measure, subinventory, locator, lot, serial number, revision, and container identifier are valid, and supplying default values (such as default subinventory and default locator) where the interface data omits them. By concentrating these checks in a single package, the open interface ensures consistent enforcement of inventory and shipping rules across all inbound delivery data.

Key Procedures and Functions

The package exposes 23 documented procedures and functions. The principal validation and defaulting routines include:

• GET_ORDER_INFO — Retrieves order-level context such as order currency and order category for a picking header.
• PICKSLIP_CLOSED — Boolean function indicating whether a picking header's pick slip has been closed.
• GET_ITEM_CONTROL_CODES and GET_LOCATOR_CONTROLS — Return item control flags (revision, lot, serial, subinventory restriction) and locator control flags for a given warehouse/item combination.
• VALID_SUBINVENTORY and DEFAULT_SUBINVENTORY — Validate a supplied subinventory for the item/warehouse and return a default when none is provided.
• VALID_LOT_NUMBER, VALID_REVISION, VALID_LOCATOR_ID, DEFAULT_LOCATOR, and VALID_SERIAL_NUMBER — Confirm that lot, revision, locator, and serial values are valid for the item and context, with locator defaulting.
• VALID_CARRIER_CODE — Validates a carrier code, the routine most frequently referenced in troubleshooting queries (including searches on "valid_carrier_code").
• VALID_FREIGHT_TYPE, VALIDATE_CURRENCY, VALIDATE_UOM, and VALIDATE_USER — Validate freight terms, currency codes, units of measure, and FND user references.
• VALIDATE_CONTAINER_ID — Confirms the container identifier used in delivery detail lines.
• AR_INTERFACED — Determines whether the associated transaction has already been interfaced to Receivables.
• UPDATE_SHIPPING_ONLINE — Applies shipping information updates during online processing.
• SHIP_MULTI_ORG — Supports shipping operations spanning multiple inventory organizations.

Tables Accessed

The package reads and writes through APPS synonyms across inventory, order, and shipping tables. Validation and defaults rely on MTL_SYSTEM_ITEMS, MTL_ITEM_SUB_INVENTORIES, MTL_ITEM_SUB_DEFAULTS, MTL_ITEM_LOC_DEFAULTS, MTL_ITEM_LOCATIONS, MTL_ITEM_REVISIONS, MTL_SECONDARY_INVENTORIES, MTL_SECONDARY_LOCATORS, MTL_SERIAL_NUMBERS, MTL_UNITS_OF_MEASURE, and MTL_PARAMETERS. Order and freight context is taken from SO_HEADERS_ALL, ORG_FREIGHT, and SO_FREIGHT_CHARGE_TYPES, while FND_USER supports user validation. These tables supply the authoritative rules against which open interface data is validated.

Usage Notes

WSH_DEL_OI_CORE is invoked indirectly by the shipping open interface concurrent processing and by shipping forms rather than being called directly by end users. It is referenced by three other packages documented in ETRM, which typically act as the calling layer that feeds interface records into these core validations. Customizations that need to replicate shipping validation behavior, or that troubleshoot rejected interface rows (for example, an invalid carrier code), commonly query or trace these routines. Because the package is classified as OTHER rather than a published API, Oracle does not guarantee its signature across releases, and direct custom calls should be treated as unsupported and validated against the specific point release in use.