Search Results okc_xprt_template_rules




Overview

OKC_XPRT_TEMPLATE_RULES is an intersection (junction) table in the OKC schema, owned by the Contracts Core product module. Its documented purpose is to resolve a many-to-many association between contract templates and the rules that govern them. In Oracle E-Business Suite releases 12.1.1 and 12.2.2, this table underpins the Contracts Expert / rules-based template framework, where reusable rule definitions are attached to a template so that the system can evaluate conditions, drive clause or template selection, and enforce authoring behavior during contract creation and amendment.

The ETRM metadata classifies this object heuristically as standalone under the Data Vault model. As a modeling suggestion, this classification is slightly counter-intuitive: an intersection entity of this kind is naturally modeled as a link, since each row associates one template with one rule through a composite business key. The "standalone" tag reflects the mined FK topology rather than the entity's semantic role, and implementers designing an analytical or Data Vault layer should treat the table as a link candidate whose parent hubs are the template and rule masters.

Key Information Stored

The table is documented with 11 physical columns. The most operationally significant columns are:

  • TEMPLATE_RULE_ID — the surrogate primary key, enforced by the OKC_XPRT_TEMPLATE_RULES_PK constraint. This is the column referenced by dependent objects.
  • TEMPLATE_ID — foreign reference to the owning contract template; the primary business-key component.
  • RULE_ID — foreign reference to the rule definition attached to the template; the second business-key component.
  • DELETED_FLAG — soft-delete indicator, allowing rule associations to be logically removed without physical deletion.
  • PUBLISHED_FLAG — indicates whether the template-rule association is in a published, active state for contract authoring.
  • OBJECT_VERSION_NUMBER — optimistic-locking column used by the Oracle ADF/BC4J framework to detect concurrent updates.
  • CREATED_BY, CREATION_DATE — standard who-columns capturing the creating user and timestamp.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns recording the most recent modification user, timestamp, and login session.

Together, TEMPLATE_ID and RULE_ID form the natural composite business key; a unique index on this pair is the expected guard against duplicate rule attachments, while TEMPLATE_RULE_ID remains the surrogate identifier used for direct lookups and FK joins.

Common Use Cases and Queries

Typical usage centers on introspecting which rules are bound to a given template or, conversely, which templates consume a given rule. A representative query lists the active rules for a template:

  • SELECT tr.template_rule_id, tr.template_id, tr.rule_id FROM okc.okc_xprt_template_rules tr WHERE tr.template_id = :template_id AND tr.deleted_flag = 'N';
  • Reporting rules that are attached to templates but not yet published: filter on PUBLISHED_FLAG = 'N' to surface configuration backlogs.
  • Reverse-impact analysis before retiring a rule: count template associations grouped by RULE_ID to identify blast radius.
  • Audit queries using CREATION_DATE and LAST_UPDATE_DATE to track when rule-to-template bindings were established or changed, supporting change-control evidence.

Related Objects

The documented relationship data shows one inbound foreign key, linking this table to the Oracle template-framework consumer:

  • XDO_DGF_TPL_RULES — references OKC_XPRT_TEMPLATE_RULES.TEMPLATE_RULE_ID, tying the contract rule binding to the document-generation template rule layer.
  • Template master (via TEMPLATE_ID) — the OKC template definition table that owns each rule association.
  • Rule master (via RULE_ID) — the OKC rule definition table supplying the evaluable logic.

In practice, consultants join these parent tables through TEMPLATE_ID and RULE_ID to resolve descriptive names for reporting, while the TEMPLATE_RULE_ID surrogate is used when correlating with XDO_DGF_TPL_RULES. The presence of DELETED_FLAG, PUBLISHED_FLAG, and OBJECT_VERSION_NUMBER confirms the table is maintained through standard OKC concurrent/UI processes rather than by direct DML.