Search Results rule_object_instance_exists

Overview

FUN_RULE_OBJECTS_PUB_W is a public PL/SQL package in the Oracle E-Business Suite Applications (APPS) schema that exposes the business logic governing rule objects within the Oracle E-Business Tax (E-Business Tax / formerly ETRM) subsystem. Rule objects are the configurable components that define how tax determination, tax calculation, and related rules behave across a given application, operating unit, and instance. The _PUB_W suffix indicates the package is a generated public wrapper, meaning the procedures presented here delegate to underlying implementation packages and are intended to be the stable, supported entry points for programmatic manipulation of rule object data.

The package is owned by APPS and is classified as OTHER in the ETRM metadata, reflecting that it is a utility/API layer rather than a tightly scoped interface. It is referenced by zero other packages according to the documented metadata, indicating it is typically called directly rather than consumed by other server-side code. The package header carries the RCS marker FUNXTMRULROBRWS.pls with version 120.3, dated 2006, which confirms its presence in the 12.1.1 codebase and its continuation into 12.2.2.

Key Procedures and Functions

• CREATE_RULE_OBJECT — Inserts a new rule object record. It accepts the full set of rule object attributes (positional parameters p1_a0 through p1_a23), returning the newly assigned x_rule_object_id along with standard API status outputs (x_return_status, x_msg_count, x_msg_data).
• UPDATE_RULE_OBJECT — Modifies an existing rule object. In addition to the attribute parameters shared with CREATE, it accepts an in/out p_object_version_number, which enforces Oracle's optimistic locking convention to prevent lost updates when concurrent sessions edit the same record.
• GET_RULE_OBJECT_REC — Retrieves a rule object record. The input signature includes p_rule_object_name, p_application_id, p_instance_label, and p_org_id, meaning lookups are keyed by business attributes (name plus application and instance context) rather than by primary key alone. Output parameters return the retrieved attribute values.
• RULE_OBJECT_INSTANCE_EXISTS — Returns a boolean/status result indicating whether a specific rule object instance already exists for the supplied contextual identifiers. This procedure is the object of the user's search and serves as a pre-validation check before CREATE is attempted.
• RULE_OBJECT_USES_PARAMETER — Determines whether a given rule object references or depends on a specified rule parameter, supporting dependency analysis during configuration or upgrade.

All procedures follow the standard EBS public API pattern: a p_init_msg_list flag to control message stack initialization, and out parameters for return status and message count/data for error propagation.

Tables Accessed

The documented metadata does not enumerate the underlying tables referenced via APPS synonyms. Based on the functional domain and naming (FUN_RULE_OBJECTS), the wrapper operates against the E-Business Tax rule object entity tables — principally the base rule object and rule object instance tables that store the definitions named by GET_RULE_OBJECT_REC and validated by RULE_OBJECT_INSTANCE_EXISTS. Read operations populate the GET output parameters; write operations (CREATE, UPDATE) insert and modify rows in the corresponding entity table, with object version numbers maintained for concurrency control.

Usage Notes

This package is normally invoked from E-Business Tax configuration forms, from concurrent programs that perform bulk rule object maintenance or migration, and from custom PL/SQL code that seeds or validates tax configuration. The most reliable use case — and the one referenced by the search term rule_object_instance_exists — is calling RULE_OBJECT_INSTANCE_EXISTS as a guard before attempting CREATE_RULE_OBJECT, avoiding duplicate-instance errors. Because it is a public wrapper, developers should prefer these procedures over the internal implementation packages, and should always inspect x_return_status for FND_API.G_RET_STS_ERROR or G_RET_STS_UNEXP_ERROR and drain the message stack via FND_MSG_PUB when x_msg_count is greater than zero.