Search Results create_rule_crit_param




Overview
Explore in AI Chat

Overview

The APPS.FUN_RULE_CRIT_PARAMS_PUB_W package is a public PL/SQL API within the Oracle E-Business Suite Financials (FUN) schema. It exposes the business logic governing the configuration of rule criteria parameters used by the Oracle EBS Transaction Manager / Rules Engine framework. In EBS 12.1.1 and 12.2.2, rules are applied to transactions (for example, to determine accounting, tax, or processing behavior) based on a defined set of criteria. Each criterion is characterized by one or more parameters, and this package provides the programmatic interface for creating, updating, and retrieving those criteria parameter records.

The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the calling user rather than the defining user. The API is classified under the generic API category "OTHER" in the documented metadata. It contains a small, well-scoped set of three documented procedures, consistent with a narrowly focused configuration API rather than a broad business-entity API.

The header comment indicates an original source revision dated 2005, reflecting the lineage of this component from the earlier EBS releases into the 12.1.x and 12.2.x code lines. The package is a wrapper (_PUB_W) that presents a stable public interface over the underlying rule criteria parameter entity logic.

Key Procedures and Functions

The documented package exposes three procedures. All three follow the standard EBS API conventions, accepting p_init_msg_list as an initialization control and returning x_return_status, x_msg_count, and x_msg_data for error and message handling.

  • CREATE_RULE_CRIT_PARAM — Creates a new rule criteria parameter record. It accepts the active message-list flag (p_init_msg_list) and the positional parameter values p1_a0 through p1_a13, and returns the generated surrogate identifier x_criteria_param_id along with the standard status and message outputs. This procedure is the entry point for adding a criterion parameter to an existing rule.
  • UPDATE_RULE_CRIT_PARAM — Updates an existing rule criteria parameter record. As with the create procedure, it accepts the initialization flag and the positional parameter values p1_a0 through p1_a13. Crucially, it also takes p_object_version_number as an IN OUT NOCOPY parameter, enforcing optimistic locking. This is the procedure associated with the user's search term update_rule_crit_param. The version number must be supplied by the caller and is incremented on a successful update, protecting against lost updates in concurrent sessions.
  • GET_RULE_CRIT_PARAM_REC — Retrieves a single rule criteria parameter record. It is keyed by p_rule_object_id and p_param_name, and returns the parameter values through the output parameters p3_a0 through p3_a13, together with the standard return status and message outputs.

The positional naming convention (p1_a0, p3_a0, etc.) indicates that these APIs are generated or wrapped from the underlying entity definition, where the concrete column mapping is encapsulated and not exposed in the public signature.

Tables Accessed

The ETRM metadata does not enumerate specific tables referenced through APPS synonyms for this package. In practice, the API operates on the rule criteria parameter entity table that stores the criteria definitions consumed by the Rules Engine. Given the create, update, and get operations, the package performs inserts, updates, and single-row primary-key or alternate-key queries against that entity table. The GET_RULE_CRIT_PARAM_REC procedure implies a retrieval keyed by rule object identifier and parameter name; the create and update procedures imply writes to the corresponding record set. Because the documentation lists no explicit referenced tables and reports zero dependent packages, any table-level detail beyond this should be confirmed against the APPS synonym definitions in the target environment.

Usage Notes

This package is typically invoked from within the Oracle EBS application tier by the Transaction Manager / Rules Engine configuration flows. In a standard configuration, it is called by the forms or setup components that maintain rule criteria parameters rather than being invoked directly by end users. Custom code may call the package when programmatically configuring rules, for example during data migration, bulk setup, or integration with external rule definitions.

Callers should observe the following conventions. Always initialize the message list as appropriate via p_init_msg_list and inspect x_return_status before proceeding. When performing updates, the caller must supply the current p_object_version_number; the procedure treats this as an IN OUT value, so the variable is refreshed on success and serves as the authoritative version token for subsequent updates. Message diagnostics should be retrieved using the standard EBS message-handling utilities whenever x_return_status indicates a error or unexpected condition. Because the package is defined with AUTHID CURRENT_USER, invoking sessions must have the requisite privileges on the underlying APPS objects through their responsibility or role.