Search Results okc_terms_templates

Overview

OKC_TERMS_TEMPLATES is a reporting view in the Oracle E-Business Suite Contracts Core (OKC) module. It exposes the business-facing attributes of contract terms templates, which are reusable definitions of clause sets, deliverables, and numbering behavior applied when authoring contracts and contract templates. In Oracle EBS 12.1.1 and 12.2.2 the view is not implemented as a standalone database object; it is a code-level view whose definition is resolved at runtime against the multi-org table OKC_TERMS_TEMPLATES_ALL. Its principal purpose is to provide a single, org-filtered projection of template header data for reports, concurrent programs, and integrations, while applying operational transformations such as migration-name decoding and multi-org security filtering through USERENV('CLIENT_INFO').

Underlying Base Objects

According to the documented view text, OKC_TERMS_TEMPLATES is defined over OKC_TERMS_TEMPLATES_ALL, aliased as TTA. The view references no other documented base objects. Two important behaviors derive from this relationship:

• Multi-org security: The WHERE clause compares NVL(ORG_ID, NVL(TO_NUMBER(DECODE(SUBSTRB(USERENV('CLIENT_INFO'),1,1),' ',NULL,SUBSTRB(USERENV('CLIENT_INFO'),1,10))),-99)) against the same expression, restricting rows to the operating unit indicated by the client information context. Rows with a null ORG_ID fall into the -99 bucket, which typically represents global or seeded data.
• Migration naming: TEMPLATE_NAME uses DECODE on ORIG_SYSTEM_REFERENCE_CODE. When the reference code equals 'OKC11510UPG', the name is translated through OKC_UTIL.DECODE_LOOKUP using the lookup type 'OKC_11510_MIG_TEMPLATES'; otherwise the stored TEMPLATE_NAME is returned unchanged. This preserves friendly names for templates migrated during the 11.5.10 upgrade.

Key Columns

• TEMPLATE_ID — Primary key of the template; the join key to clause and deliverable child tables.
• TEMPLATE_NAME — Display name, subject to the migration decode described above.
• PARENT_TEMPLATE_ID — Identifies the source template from which a working copy or variant was derived; the column most relevant to "parent_template_id" searches. Null values indicate a top-level template.
• WORKING_COPY_FLAG — Distinguishes an in-progress copy from a released template.
• INTENT — Business intent of the template (for example, buy or sell oriented usage).
• STATUS_CODE, START_DATE, END_DATE — Lifecycle state and effective dating of the template.
• GLOBAL_FLAG — Indicates a template available across operating units.
• CONTRACT_EXPERT_ENABLED, TEMPLATE_MODEL_ID, INSTRUCTION_TEXT, TMPL_NUMBERING_SCHEME, PRINT_TEMPLATE_ID — Authoring, expert-system, numbering, and document-printing configuration.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, OBJECT_VERSION_NUMBER — Standard audit and optimistic-locking columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — Descriptive flexfield segments; HIDE_YN controls display.

Common Use Cases and Queries

Typical uses include reporting template hierarchies, locating working copies derived from a parent, and driving integrations that create contracts from a template. The parent relationship is the most frequent navigational path.

Locate all working copies derived from a given parent:

• SELECT TEMPLATE_ID, TEMPLATE_NAME, WORKING_COPY_FLAG, STATUS_CODE FROM OKC_TERMS_TEMPLATES WHERE PARENT_TEMPLATE_ID = :p_parent_id;

List top-level templates in the current operating unit:

• SELECT TEMPLATE_ID, TEMPLATE_NAME, GLOBAL_FLAG FROM OKC_TERMS_TEMPLATES WHERE PARENT_TEMPLATE_ID IS NULL AND STATUS_CODE = 'ACTIVE';

Join templates to their parents to show hierarchy:

• SELECT C.TEMPLATE_NAME child_name, P.TEMPLATE_NAME parent_name FROM OKC_TERMS_TEMPLATES C, OKC_TERMS_TEMPLATES P WHERE C.PARENT_TEMPLATE_ID = P.TEMPLATE_ID;

Because the view enforces ORG_ID filtering through USERENV('CLIENT_INFO'), queries executed outside a properly initialized session (for example, raw SQL*Plus without an operating-unit context) may return only the -99 global rows or none at all. Integrations and reports should therefore set the client information context via FND_GLOBAL or the standard multi-org initialization APIs before querying.