Search Results hxc_locking_rules




Overview
Explore in AI Chat

Overview

The HXC_LOCKING_RULES table is a core data object within the Oracle E-Business Suite (EBS) Time and Labor Engine (HXC). It functions as a configuration table that defines the rules governing how different timecard lockers interact within the system. A locker, represented by the HXC_LOCKER_TYPES table, is a logical entity that can lock a timecard to prevent further edits, such as a supervisor or a payroll process. This table establishes the permissible relationships between these lockers, specifically dictating which locker types (the requestor) can lock timecards already held by other locker types (the owner). Its role is critical for enforcing business rules around timecard workflow, security, and data integrity during approval and processing cycles.

Key Information Stored

The table's structure is concise, centering on the relationship between two locker types. The primary key is a composite of two columns, both of which are foreign keys to the HXC_LOCKER_TYPES table. The LOCKER_TYPE_OWNER_ID column stores the identifier for the locker type that currently possesses the lock on a timecard. The LOCKER_TYPE_REQUESTOR_ID column stores the identifier for a different locker type that is attempting to acquire the lock. The existence of a record in this table signifies that the requestor locker type is authorized to take over the lock from the owner locker type. This simple pair of IDs encapsulates the rule that enables sequenced locking control in time and labor management.

Common Use Cases and Queries

The primary use case is the validation of lock transition requests. When a process or user attempts to lock a timecard, the system queries this table to verify if the action is permitted based on the current lock holder. A common reporting need is to audit or review all defined locking rules. A sample query to list these rules, joining to get the descriptive names of the locker types, would be:

  • SELECT owner_locker.LOCKER_TYPE_NAME AS CURRENT_OWNER, requestor_locker.LOCKER_TYPE_NAME AS AUTHORIZED_REQUESTOR FROM HXC_LOCKING_RULES rules, HXC_LOCKER_TYPES owner_locker, HXC_LOCKER_TYPES requestor_locker WHERE rules.LOCKER_TYPE_OWNER_ID = owner_locker.LOCKER_TYPE_ID AND rules.LOCKER_TYPE_REQUESTOR_ID = requestor_locker.LOCKER_TYPE_ID ORDER BY 1, 2;

Another critical query pattern checks for the existence of a specific rule, which is central to the locking engine's logic: verifying if a given requestor_id can lock a timecard held by a given owner_id.

Related Objects

The HXC_LOCKING_RULES table has direct, documented relationships with a single other table, HXC_LOCKER_TYPES. It references this table twice through foreign key constraints, forming the entirety of its data model relationships.

  • HXC_LOCKER_TYPES: This table is referenced twice by HXC_LOCKING_RULES.
    • Foreign Key: HXC_LOCKING_RULES.LOCKER_TYPE_OWNER_ID → HXC_LOCKER_TYPES (provides details on the current lock owner type).
    • Foreign Key: HXC_LOCKING_RULES.LOCKER_TYPE_REQUESTOR_ID → HXC_LOCKER_TYPES (provides details on the authorized requesting locker type).

The table's primary key, HXC_LOCKING_RULES_PK, is defined on the combination of LOCKER_TYPE_OWNER_ID and LOCKER_TYPE_REQUESTOR_ID, ensuring each locking rule is unique.