Search Results okc_rules_bh_pk

Overview

OKC_RULES_BH is the history (audit) table for OKC_RULES_B within the OKC – Contracts Core product of Oracle E-Business Suite. The _BH suffix is the standard Oracle EBS convention for a shadow table that preserves prior versions of a base transactional table: whenever a rule row in OKC_RULES_B is updated or deleted, the pre-change image is copied into OKC_RULES_BH, together with an incrementing version stamp. OKC_RULES_B itself stores the rules that govern contract clauses, templates, and related contract objects — for example which standard or non-standard clauses may be combined, which combinations should trigger a warning, and the display ordering of answers. OKC_RULES_BH therefore provides the temporal record of those governance definitions.

Because the table carries both ID and MAJOR_VERSION and no foreign keys to any transactional entity other than a security grouping, the mined Data Vault classification is standalone. A reasonable modeling suggestion is to treat it as a satellite-style version history over the OKC_RULES_B hub, with (ID, MAJOR_VERSION) acting as the effective-dated key.

Key Information Stored

The table is documented with 61 columns. The most significant are:

• ID – identifier of the rule; part of the composite primary key and of the unique index OKC_RULES_BH_U1.
• MAJOR_VERSION – version sequence number; the second component of both the primary key (OKC_RULES_BH_PK) and the unique index. Together with ID it forms the business-key candidate for a specific historical version.
• RGP_ID – the rule group to which the rule belonged, tying the history row back to its grouping context.
• OBJECT1_ID1, OBJECT2_ID1, OBJECT3_ID1 and OBJECT1_ID2, OBJECT2_ID2, OBJECT3_ID2 – the three-part object coordinates identifying the two objects the rule relates (e.g., clause/answer pairs).
• JTOT_OBJECT1_CODE, JTOT_OBJECT2_CODE, JTOT_OBJECT3_CODE – the "join to object type" codes that qualify each object identifier.
• ANS_SET_JTOT_OBJECT_CODE, ANS_SET_JTOT_OBJECT_ID1, ANS_SET_JTOT_OBJECT_ID2 – identify the associated answer set object.
• DNZ_CHR_ID – the contract (or document) identifier in the DNZ contract model to which the rule applies.
• STD_TEMPLATE_YN, TEMPLATE_YN, WARN_YN – Yes/No flags indicating standard-template applicability, template usage, and whether a warning is raised on violation.
• PRIORITY and DISPLAY_SEQUENCE – ordering controls for rule evaluation and presentation.
• OBJECT_VERSION_NUMBER – optimistic-locking counter in the base table.
• RULE_INFORMATION_CATEGORY and RULE_INFORMATION1…15 – the DFF-style descriptive flexfield segment reserved for rule-specific attributes.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1…15 – the standard EBS attribute flexfield.
• SECURITY_GROUP_ID – foreign key to FND_SECURITY_GROUPS, supporting multi-tenant/data-security filtering.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – standard WHO audit columns.
• COMMENTS – free-text annotation.

Common Use Cases and Queries

The primary use case is auditing rule changes over time — determining who changed a contract rule, when, and what the prior definition looked like.

• Current version lookup: select the highest MAJOR_VERSION per ID.
• Change history for one rule: SELECT id, major_version, last_updated_by, last_update_date, warn_yn, priority FROM okc_rules_bh WHERE id = :rule_id ORDER BY major_version;
• Comparison of base versus history: join OKC_RULES_B to OKC_RULES_BH on ID to spot discrepancies.
• Point-in-time reconstruction: filter on LAST_UPDATE_DATE to see the rule definition in force on a past date.
• Security-scoped reporting: join to FND_SECURITY_GROUPS via SECURITY_GROUP_ID.

Because the table can grow quickly, reporting queries should always be bounded by ID or a date range and should avoid full scans.

Related Objects

• OKC_RULES_B – the base table whose prior images this history table stores; join on ID.
• OKC_RULES_BH_PK / OKC_RULES_BH_U1 – the primary key and unique index over (ID, MAJOR_VERSION).
• FND_SECURITY_GROUPS – referenced by SECURITY_GROUP_ID, providing data-security grouping.
• OKC_RULE_GROUPS (via RGP_ID) – the rule-group parent that organizes rules.
• OKC_TERMS / OKC_TEMPLATES – contract terms and template definitions governed by these rules and linked via DNZ_CHR_ID and template flags.
• OKC_RULES_TL – translated rule names/descriptions for the corresponding ID.