Search Results okc_sections_index_v

Overview

OKC_SECTIONS_INDEX_V is a database view owned by the APPS schema within the OKC — Contracts Core product module of Oracle E-Business Suite, documented and valid in releases 12.1.1 and 12.2.2. Its documented purpose is to serve as the treewalk sections index provider for the Contracts Core contract authoring and repository framework.

In Oracle Contracts, contract content is organized into a hierarchical structure of sections and subsections. The underlying storage table OKC_SECTIONS_B holds each section as a row, linked to its parent through the SCN_ID column. Consumers of this hierarchy — most notably the Contract Terms and Conditions authoring UI, treewalk navigation components, printing and publishing engines, and document generation routines — require each section to be assigned a stable, ordered, human-readable index value that reflects its position in the tree (for example, a numbering scheme such as 1, 1.1, 1.1.1 that corresponds to nesting depth). OKC_SECTIONS_INDEX_V supplies exactly that mapping. Rather than persisting derived positional values, the view computes them on demand using a hierarchical CONNECT BY query combined with helper functions from the OKC_TREE_INDEX package, so the index remains consistent with the current structure of the section tree at query time.

Underlying Base Objects

According to the documented ETRM metadata, OKC_SECTIONS_INDEX_V references two objects:

• OKC_SECTIONS_B (SYNONYM) — the base table storing contract section definitions, including the ID of each section, its parent section reference (SCN_ID), the owning contract header (CHR_ID), and the section ordering attribute (SECTION_SEQUENCE) used to determine sibling order.
• OKC_TREE_INDEX (PACKAGE) — a PL/SQL package exposing utility functions invoked directly inside the view SQL: GET_ID, GET_ID_LPADED, and GET_ROOT_ID.

The view text performs a hierarchical traversal of OKC_SECTIONS_B using CONNECT BY PRIOR ID = SCN_ID, starting with rows whose CHR_ID equals the root identifier returned by OKC_TREE_INDEX.GET_ROOT_ID and whose SCN_ID is NULL (that is, the top-level sections). The LEVEL pseudocolumn produced by the hierarchy is passed to the package functions to derive the index values.

Key Columns

The view exposes three columns as documented:

• ID — the section identifier inherited from OKC_SECTIONS_B, uniquely identifying each contract section row within the tree.
• SECTION_INDEX — the treewalk index value computed by OKC_TREE_INDEX.GET_ID(LEVEL, SECTION_SEQUENCE). This produces the positional index for the section based on its depth in the hierarchy and its configured sequence among siblings; it is the value consumed by treewalk navigation and authoring components.
• SECTION_ORDER — the padded ordering value produced by OKC_TREE_INDEX.GET_ID_LPADED(LEVEL, SECTION_SEQUENCE, 5, 2). Because string-based ordering of index values such as 1, 10, and 2 is unreliable, this column left-pads the numeric components (documented width parameters of 5 and 2) so that lexicographic sorting yields the correct hierarchical sequence. It is used for ORDER BY clauses in reports and UI queries.

Common Use Cases and Queries

The view is typically queried when reports, integrations, or extensions must reproduce the section numbering and ordering that the Contracts Core UI presents to users, without duplicating the treewalk logic. Typical scenarios include generating contract documents where sections must appear numbered in tree order, feeding section data to conversion or interface programs, and building custom section indexes or audits for a contract header.

A representative query lists the sections of a given contract in display order, joining the contract header ID through OKC_SECTIONS_B where additional attributes are required:

• SELECT i.id, i.section_index, i.section_order FROM okc_sections_index_v i, okc_sections_b s WHERE i.id = s.id AND s.chr_id = :contract_id ORDER BY i.section_order;
• SELECT i.section_index FROM okc_sections_index_v i WHERE i.id = :section_id; — retrieving the index value for a single known section, for example to label a section in a custom form or concurrent program output.

Because the index is computed via CONNECT BY over the live section table, results always reflect the current hierarchy and sibling sequencing; no staging or refresh is required. Note that the CONNECT BY predicate restricts root selection to a single contract subtree (SCN_ID IS NULL AND CHR_ID = root), so queries should generally be scoped to one contract header at a time.