Search Results fun_rule_crit_params_pub




Overview
Explore in AI Chat

Overview

The APPS.FUN_RULE_CRIT_PARAMS_PUB package is a public (PUB-classified) PL/SQL API within the Oracle E-Business Suite Financials (FUN) schema. It belongs to the ETRM (Enterprise Transaction Rules Management) framework, which governs the rule-based transaction processing logic used across Oracle Payables, Receivables, Purchasing, and related modules. Specifically, this package manages the criteria parameters associated with transaction rules — the individual conditions that determine whether a given rule fires when a transaction is evaluated.

In ETRM, a rule is composed of a rule header and one or more associated criteria. Each criterion defines a condition (for example, a supplier, an amount threshold, or an attribute value) that must be satisfied. FUN_RULE_CRIT_PARAMS_PUB provides the programmatic interface for creating, maintaining, retrieving, and deleting these criteria parameter records. As a public API, it is the supported entry point through which both Oracle's own seeded components and customer extensions interact with the underlying criteria tables, ensuring that business validation and setup consistency checks are applied uniformly.

Key Procedures and Functions

The package exposes five documented procedures and functions:

  • CREATE_RULE_CRIT_PARAM — Creates a single rule criteria parameter record, associating a criterion with its parent rule and persisting the detail definition to the base and translation tables.
  • CREATE_DUP_RULE_CRIT_PARAMS — Creates duplicated rule criteria parameters, supporting the common setup pattern of copying an existing set of criteria, such as when cloning a rule definition or mass-maintaining similar rules.
  • UPDATE_RULE_CRIT_PARAM — Modifies an existing criteria parameter record, allowing setup changes to be applied to previously defined rule criteria.
  • GET_RULE_CRIT_PARAM_REC — Retrieves a single rule criteria parameter record, returning the current definition for a specified criterion so that callers can inspect or propagate its values.
  • DELETE_RULE_CRIT_PARAM — Removes a rule criteria parameter record, retiring a condition that is no longer required by the owning rule.

As a published API, the package builds upon the standard Oracle API framework, notably FND_API and its associated types and utilities, which supply the consistent error-handling and return-status conventions expected of EBS public APIs.

Tables Accessed

The package reads from and writes to the following tables through APPS synonyms:

  • FUN_RULE_CRIT_PARAMS_B — The base table storing the criteria parameter definitions. This is the primary target of create, update, and delete operations.
  • FUN_RULE_CRIT_PARAMS_TL — The translation table holding language-specific descriptive text for each criteria parameter. Records created through this API populate both the base and translation rows to maintain multilanguage support.
  • FUN_RULE_OBJECTS_B — The base table of rule objects, providing the parent context that links criteria parameters to the rules and object definitions they qualify.

Usage Notes

FUN_RULE_CRIT_PARAMS_PUB is referenced by three other packages — FUN_RULE_CRIT_PARAMS_PUB_W, FUN_RULE_OBJECTS_PUB, and FUN_RULE_VALIDATE_PKG — reflecting its role as a foundational component of the ETRM rule setup and validation layer. The wrapper package typically supplies a thin callable surface, while the validation package consumes this API when confirming that rule definitions are complete and consistent.

The API is ordinarily invoked through the ETRM rule setup forms in Oracle EBS, where administrators define rules and their criteria. It may also be called from concurrent programs that bulk-load or migrate rule configurations, and from custom PL/SQL code extending ETRM functionality. Because the package enforces the standard EBS API contract, custom callers should observe the documented return status and error-handling conventions rather than writing directly to the underlying tables. Direct DML against FUN_RULE_CRIT_PARAMS_B and its translation table bypasses validation logic and is not recommended.