Search Results p_locator_id

Overview

WIP_LOCATOR is a Work in Process (WIP) package body owned by the APPS schema that centralizes locator validation logic for manufacturing and inventory transactions. Its principal responsibility is to determine whether a given locator is required, permitted, or must be cleared, based on the locator control rules that apply to an organization, subinventory, and item combination. The package encapsulates calls to the shared inventory locator control engine (QLTINVCB) and the Oracle Applications key flexfield validation APIs, shielding calling modules from the conditional logic required to interpret locator control settings correctly.

In Oracle EBS 12.1.1 and 12.2.2, locator control may be defined at the organization, subinventory, or item level, and the effective control can be "no control," "pre-specified," or "dynamic entry." WIP_LOCATOR resolves this hierarchy and returns a validated locator identifier or locator flexfield segment string. Because the package surfaces locator control decisions as a reusable API, it is invoked from multiple WIP transaction paths rather than duplicating validation rules in each form or program.

The package is documented as API classification OTHER and is referenced by eight other packages, indicating its role as a shared internal utility within the WIP and inventory integration layer.

Key Procedures and Functions

The ETRM metadata documents a single procedure, VALIDATE. The following describes its purpose without restating its parameter list.

• Validate — Determines whether the supplied locator information is consistent with the applicable locator control rules and returns a normalized locator identifier and locator segment string, together with a success flag. The procedure accepts organization, item, subinventory, and control-indicator inputs, along with an action code and optional project and task context. The locator identifier and locator segments are passed as IN OUT parameters so the procedure may either confirm or replace the caller's values. When no locator control applies, the procedure clears the locator identifier and segments and reports success, unless the caller supplied locator values, in which case validation fails. A special treatment is applied when the subinventory code equals fnd_api.g_miss_char, which suppresses locator validation. For pre-specified control, the procedure performs a flexfield combination check, with additional restriction handling depending on the restriction flag. Callers are expected to inspect the success flag before proceeding with the transaction.

Tables Accessed

The package references two tables through APPS synonyms.

• MTL_ITEM_LOCATIONS — The inventory locator master. It is used to resolve and confirm that a locator identifier exists, is enabled, and is valid within the given organization and subinventory. Locator flexfield segment values are derived from this table.
• MTL_SECONDARY_LOCATORS — Stores secondary locator associations. It supports validation when locators carry secondary locator definitions, ensuring the resolved locator is consistent with the secondary locator configuration in use.

Usage Notes

WIP_LOCATOR is an internal WIP validation utility rather than a public, published API. It is most commonly invoked from WIP transaction forms and from other PL/SQL packages that need to validate a locator before performing a move, completion, return, or issue. Custom code that must enforce the same locator control behavior should call VALIDATE rather than querying MTL_ITEM_LOCATIONS directly, because the procedure also evaluates the organization, subinventory, and item control precedence and applies flexfield combination checking.

Callers must treat the success flag as authoritative and must not assume that the returned locator identifier matches the value they supplied; on failure the returned identifier should be discarded. Because the subinventory parameter accepts fnd_api.g_miss_char as a signal to skip validation, custom callers should avoid passing that sentinel value unless locator validation is genuinely not required. The package does not commit transactions; commit and rollback remain the responsibility of the calling form, concurrent program, or API layer.