Search Results wms_rule_form_pkg




Overview
Explore in AI Chat

Overview

APPS.WMS_RULE_FORM_PKG is a PL/SQL package that supports the Oracle Warehouse Management (WMS) rule definition form in Oracle E-Business Suite 12.1.1 and 12.2.2. It provides the server-side API layer behind the user interface used to create, maintain, lock, and deploy picking, put-away, and other WMS rule configurations. The package encapsulates the business logic required to validate and persist rule definitions across the WMS rule tables, ensuring that data entered through the form remains consistent with the underlying warehouse management engine.

Because the form operates against multiple related entities — rule headers, rule versions, restrictions, sort criteria, and consistency checks — the package mediates between the form block and those tables, returning standard API-style status, message count, and message data outputs that the form uses to raise errors or confirmations to the user.

Key Procedures and Functions

The documented package exposes seven procedures and functions:

  • INSERT_RULE — Creates a new WMS rule definition. It accepts rule attributes such as organization, type code, quantity function parameter, enabled and user-defined flags, minimum pick tasks flag, descriptive flexfield attributes, name, description, type header, rule weight, and allocation mode. It returns a generated rule identifier and standard API return status outputs.
  • LOCK_RULE — Invoked when a user locks a rule record for editing or when the rule is locked within the form workflow. This is the procedure most commonly surfaced by the search term "lock_rule." It accepts the rule identifier plus the rule's attribute values and returns the standard status, message count, and message data outputs.
  • UPDATE_RULE — Modifies an existing rule definition, preserving the rule identifier while changing its configurable attributes.
  • FIND_RULE — Queries rule definitions, typically in support of form query-by-example or search behavior, returning matching rule records.
  • DELETE_RULE — Removes a rule definition (or marks it for removal) subject to validation constraints.
  • COPY_RULE — Duplicates an existing rule, allowing users to create a new rule based on a prior configuration. This is a common convenience when many rules share a similar structure.
  • CHECK_WMS_RULE_EXISTS — Performs an existence check, generally used for validation before insert, update, or copy operations to avoid duplicate or conflicting definitions.

Tables Accessed

The package operates against the following documented tables via APPS synonyms:

  • WMS_RULES and its _B and _S counterparts — the base (entity), _B (base) and _S (translation) rule definition tables. These store the core rule attributes written by INSERT_RULE and UPDATE_RULE and read by FIND_RULE.
  • WMS_RESTRICTIONS — stores restriction conditions associated with rules, defining the scope in which each rule applies.
  • WMS_RULE_CONSISTENCIES and WMS_RULE_CONSISTENCIES_S — base and translation tables for rule consistency settings.
  • WMS_SORT_CRITERIA — stores sort criteria used by rules, particularly relevant for put-away and picking sequencing logic.
  • DUAL — used for lightweight existence and validation checks such as CHECK_WMS_RULE_EXISTS.

Usage Notes

WMS_RULE_FORM_PKG is invoked primarily by the WMS rule setup form. The form calls INSERT_RULE, UPDATE_RULE, DELETE_RULE, COPY_RULE, FIND_RULE, and LOCK_RULE in response to user actions, and uses CHECK_WMS_RULE_EXISTS to validate data prior to committing changes. The package is also referenced by two other packages, indicating that some rule-related logic is shared or reused elsewhere in the WMS codebase.

Because it follows the standard API conventions with x_return_status, x_msg_count, and x_msg_data outputs and uses FND_API defaults for message list initialization and validation level, the package is suitable for invocation from custom code or concurrent programs, provided callers honor the validation level and message handling conventions. It is not intended to be called directly by end users; all access should be mediated through the supported form or by custom code that respects the same validation behavior.

The source header indicates an origin date of 2005 and version 120.1, reflecting the package's long-standing stability across the 11i through 12.2.x releases.