Search Results wms_rule_op_pkg2

Overview

APPS.WMS_RULE_OP_PKG2 is a server-side PL/SQL package in the Oracle Warehouse Management (WMS) module of Oracle E-Business Suite. Its name denotes its role as a rule-processing utility specifically concerned with operation plan rules within the warehouse execution engine. In Oracle WMS, a "rule" is a configurable decision object that the warehouse execution engine evaluates at runtime to determine how a given transaction (put-away, picking, replenishment, or similar) should be handled — which subinventory, locator, cost group, or operation sequence applies. The suffix "OP" in the package name stands for Operation Plan, and the package exposes a single documented entry point, EXECUTE_OP_RULE, whose stated purpose in the source is "For Opening the Operation Plan CURSOR." The package therefore participates in the rule-evaluation pipeline: given a rule identifier and a transaction type context, it opens and drives the cursor that materialises the operation-plan rule definition, enabling the calling WMS runtime code to apply the resulting plan to an in-flight material transaction.

The package is classified as an "OTHER" API in ETRM 12.2.2, meaning Oracle does not document it as a public, supported integration API. It is an internal WMS execution object intended for use by the WMS engine and by other WMS packages (one package is documented as referencing it). This classification is important: callers should treat it as engine-internal rather than a stable extension point.

Key Procedures and Functions

The documented package specification contains exactly one procedure:

• EXECUTE_OP_RULE — Documented in the specification header as "For Opening the Operation Plan CURSOR." The procedure accepts a rule identifier and a transaction type identifier as its inputs and returns a status value to the caller. Its role is to locate the configured operation-plan rule matching the supplied rule and transaction-type context, open the associated cursor, and make the rule's operation-plan definition available to the WMS runtime so that the applicable warehouse operations are generated for the transaction being processed. The non-NOCOPY x_return_status output follows the standard WMS/EBS convention of signalling success or failure back to the invoking layer.

No other procedures or functions are documented in the package specification at the 12.2.2 metadata level. No parameter details beyond those shown in the excerpted specification are asserted here.

Tables Accessed

The ETRM metadata excerpt provided does not enumerate the base tables accessed by WMS_RULE_OP_PKG2 via APPS synonyms. Functionally, a rule-evaluation routine of this kind operates against the WMS rules and operation-plan configuration schema — principally the rule definition tables that hold the rule header, rule criteria, and the operation-plan steps bound to a given rule and transaction type, together with the transaction-type reference data used to qualify the lookup. Because the documented table list is empty, the precise underlying objects should be confirmed against the live 12.1.1 or 12.2.2 deployment rather than assumed. The package performs read-oriented work to resolve the rule definition cursor; any write activity is incidental to plan generation managed by the calling runtime.

Usage Notes

WMS_RULE_OP_PKG2 is invoked internally by the Oracle WMS execution engine, not directly by end users. The typical invocation path is from another WMS package during the evaluation of warehouse execution rules for an in-progress material transaction; the cursor opened by EXECUTE_OP_RULE feeds the operation-plan generation logic. Consequently, it is not exposed through a standard Oracle Forms window, concurrent program, or menu function in the shipped application, and it should not be relied upon as a supported integration API given its "OTHER" classification.

• Upgrade considerations: Because this package is engine-internal, its signature and behaviour may change between 12.1.1 and 12.2.2 without Oracle documenting the change. Custom code that calls it directly — particularly if it caches a compiled reference to the specification — carries upgrade risk.
• Customisation guidance: Where extension is required, prefer Oracle-documented WMS rule configuration and supported APIs. If direct invocation is unavoidable, always inspect x_return_status and treat any non-success value as a hard failure of the rule evaluation, since a failed cursor open will leave the operation plan unresolved and can block or misroute the upstream transaction.
• Testing: Any custom caller should be regression-tested against both 12.1.1 and 12.2.2, as the referenced-package and table dependencies are not published in ETRM and may drift across patch levels.