Search Results okc_rules_bh_u1

Overview

OKC.OKC_RULES_BH is the history (audit) table for OKC_RULES_B within the Oracle E-Business Suite Contracts (OKC) module. It stores the complete versioned record set of contract rule definitions, preserving prior and current editions of each rule row so that rule behavior tied to a specific MAJOR_VERSION can be reconstructed. The table is owned by the OKC schema, registered in FND Design Data as OKC.OKC_RULES_BH, holds VALID status, contains 61 documented columns, and resides in the APPS_TS_TX_DATA tablespace with PCTFREE 10. Its unique index OKC_RULES_BH_U1 is created on the columns (ID, MAJOR_VERSION), which is the precise index name referenced in the user's search.

Functionally, a "rule" in OKC represents a routing, notification, or process rule attached to a contract or contract template. OKC_RULES_BH captures those rules across versions, including template-derived rules, warning flags, priority, and the display sequence in which rules are evaluated. The Data Vault classification mined from the foreign-key structure is standalone; as a modeling suggestion this indicates the table does not behave as a clean hub, link, or satellite but rather as a versioned, denormalized history entity carrying its own business keys. Designers should treat it as a versioned satellite-like structure that holds contract rule state per major version rather than as a pure conformed dimension.

Key Information Stored

The primary key is OKC_RULES_BH_PK, defined on (ID, MAJOR_VERSION). ID is the surrogate primary key column inherited from the base table, and MAJOR_VERSION distinguishes successive editions of the same rule. The unique index OKC_RULES_BH_U1 spans exactly these two columns and therefore serves as the business-key candidate for identifying one specific versioned rule instance. The non-unique index OKC_RULES_BH_N1 on DNZ_CHR_ID supports contract-level retrieval.

• ID — primary key column identifying the rule.
• MAJOR_VERSION — the version discriminator that, together with ID, forms the unique key.
• RGP_ID — identifier of the rule group to which the rule belongs.
• DNZ_CHR_ID — the contract ID, denormalized for performance and indexed by OKC_RULES_BH_N1.
• OBJECT1_ID1, OBJECT2_ID1, OBJECT3_ID1 — first parts of the primary keys of the OKX views named by the corresponding JTOT_OBJECT_CODE columns.
• OBJECT1_ID2, OBJECT2_ID2, OBJECT3_ID2 — second parts of those referenced view primary keys.
• JTOT_OBJECT1_CODE, JTOT_OBJECT2_CODE, JTOT_OBJECT3_CODE — foreign keys to JTF_OBJECTS_B identifying the view referenced by each OBJECT_ID pair.
• STD_TEMPLATE_YN — indicates whether the rule originates from a template contract.
• TEMPLATE_YN — further template indicator retained on the history row.
• WARN_YN — indicates whether the contract person in charge must be alerted.
• PRIORITY — evaluation priority of the rule.
• DISPLAY_SEQUENCE — ordering used when presenting rules.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, controlling row-level access.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the concurrent framework.
• COMMENTS and the standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) — audit and descriptive context.

The fifteen ATTRIBUTE and fifteen RULE_INFORMATION flex columns provide extensibility for customer-specific rule data without schema change.

Common Use Cases and Queries

Typical reporting scenarios include reconstructing the rule set in force for a contract as of a given version, comparing rule changes between versions, and auditing who altered warning or priority settings. A representative query joining the history table to the base table on both key columns is:

• SELECT h.ID, h.MAJOR_VERSION, h.DNZ_CHR_ID, h.WARN_YN, h.PRIORITY FROM OKC.OKC_RULES_BH h WHERE h.DNZ_CHR_ID = :contract_id ORDER BY h.ID, h.MAJOR_VERSION;
• SELECT h.ID, h.MAJOR_VERSION, h.RGP_ID, h.STD_TEMPLATE_YN FROM OKC.OKC_RULES_BH h WHERE h.ID = :rule_id;
• SELECT h.ID, h.MAJOR_VERSION, b.PRIORITY FROM OKC.OKC_RULES_BH h JOIN OKC.OKC_RULES_B b ON b.ID = h.ID AND b.MAJOR_VERSION <= h.MAJOR_VERSION WHERE h.ID = :rule_id;
• SELECT COUNT(*), DNZ_CHR_ID FROM OKC.OKC_RULES_BH WHERE TEMPLATE_YN = 'Y' GROUP BY DNZ_CHR_ID;

Because OKC_RULES_BH_N1 covers DNZ_CHR_ID and OKC_RULES_BH_U1 covers (ID, MAJOR_VERSION), these access paths are the most efficient for contract-centric and version-centric reporting respectively. Change-detection reporting should compare successive MAJOR_VERSION rows per ID to isolate added, modified, or retired rules.

Related Objects

The most significant dependencies are:

• OKC.OKC_RULES_B — the base (non-history) rule table; OKC_RULES_BH mirrors it per MAJOR_VERSION.
• FND_SECURITY_GROUPS — referenced by OKC_RULES_BH.SECURITY_GROUP_ID for row-level security.
• JTF_OBJECTS_B — referenced by JTOT_OBJECT1_CODE, JTOT_OBJECT2_CODE, and JTOT_OBJECT3_CODE to identify each OKX view.
• OKX views — the target objects whose primary keys are stored in the OBJECT_ID1/OBJECT_ID2 column pairs.
• Rule group objects — referenced through RGP_ID, linking rules to their grouping construct.
• OKC contract entities — joined via DNZ_CHR_ID to the contract header and related OKC contract tables.

Application programming interfaces that maintain contract rules operate against OKC_RULES_B and propagate versioned rows into OKC_RULES_BH, so transactional integrations should treat the history table as read-mostly audit data rather than a directly updatable interface.