Search Results hxc_time_entry_rule_group_api




Overview
Explore in AI Chat

Overview

The APPS.HXC_TIME_ENTRY_RULE_GROUP_API package is a server-side PL/SQL API within the Oracle E-Business Suite Time and Labor (also referred to as Time and Labor / OTL, or the E-Business Time Recording and Management, ETRM) product family. It provides the programmatic interface for creating, maintaining, and removing time entry rule groups. A time entry rule group is a logical container that aggregates one or more components — for example, time entry rules, validation rules, and related configuration elements — under a single named entity so that they can be assigned and applied consistently across workers, assignments, or organizational structures.

Consistent with the Oracle EBS "API" classification, this package encapsulates the business rules, validation logic, and multi-table persistence operations that would otherwise have to be duplicated by any client that manipulates rule groups directly against the underlying schema. By exposing controlled procedures rather than raw table access, the API preserves data integrity, enforces naming constraints, and ensures that dependent entities are managed in a consistent sequence. The package is owned by the APPS schema and is marked VALID in the referenced release levels (12.1.1 and 12.2.2). The ETRM metadata indicates that no other packages reference this API, which suggests it is intended primarily as a top-level entry point invoked by forms, concurrent programs, or custom extensions rather than being consumed internally by other APIs.

Key Procedures and Functions

The package exposes five documented procedures and functions, each mapping to a distinct lifecycle operation on a time entry rule group:

  • CREATE_TIME_ENTRY_RULE_GROUP — Inserts a new time entry rule group definition, including its associating components. This is the primary entry point for establishing a new grouping of rule components.
  • UPDATE_TIME_ENTRY_RULE_GROUP — Modifies the attributes of an existing rule group, such as its name or the set of components it contains.
  • DELETE_TIME_ENTRY_RULE_GROUP — Removes a rule group and its associated component associations from the system.
  • CHK_NAME — A validation routine that verifies the uniqueness and validity of a rule group name, preventing duplicate or conflicting group definitions.
  • CHK_DELETE — A validation routine that determines whether a given rule group is eligible for deletion, guarding against removal of a group that is still referenced or otherwise in use.

The pairing of the change procedures with CHK_NAME and CHK_DELETE reflects a standard EBS API pattern in which validation logic is separated from persistence logic, allowing the same checks to be reused and invoked consistently.

Tables Accessed

The API operates against two core tables, accessed through APPS synonyms:

  • HXC_ENTITY_GROUPS — Stores the master record for each rule group, holding the group's identifying and descriptive attributes.
  • HXC_ENTITY_GROUP_COMPS — Stores the component memberships that link individual rule components to their parent entity group, defining the composition of each group.

Together these tables provide the header-detail structure that the API maintains: HXC_ENTITY_GROUPS for the group header and HXC_ENTITY_GROUP_COMPS for the component assignments. The create, update, and delete procedures write to these tables, while the check procedures read from them to validate naming and deletion eligibility.

Usage Notes

This package is typically invoked from the Time and Labor setup forms, from concurrent programs that seed or migrate rule group definitions, and from custom PL/SQL or OAF extensions that need to manage rule groups programmatically. Because the metadata records no inbound references from other packages, callers should treat it as a standalone API and invoke it directly rather than expecting it to be wrapped by another layer.

When integrating, callers should invoke CHK_NAME before create or update, and CHK_DELETE before delete, to surface validation errors through the standard EBS message stack rather than relying on database exceptions. All calls should be executed within an APPS-schema session with the standard EBS initialization (FND_GLOBAL) in place, and custom code should commit or roll back explicitly according to the surrounding transaction boundaries.