Search Results left_ctr_master_id




Overview
Explore in AI Chat

Overview

OKC_CNL_COUNTER_EXPR_V is a reporting view owned by the APPS schema within the Oracle Contracts Core (OKC) module. Its documented purpose is to expose data originating from the OKC_EVENT_DEF_LINES_B table structure, and it is validated as a deployed database object in Oracle E-Business Suite 12.1.1 and 12.2.2. Functionally the view presents the counter-expression rows that make up conditional logic defined on contract terms. It isolates a specific line type — CEX, the counter-expression category — from the broader OKC_CONDITION_LINES_B base table, producing a denormalized, language-resolved result set for the seeded and user-defined conditions evaluated during contract authoring and pricing. Because it joins the base entity table to its translation table, the view returns descriptions in the session language rather than requiring callers to perform that join independently, which makes it a convenient read interface for reporting, integration extracts, and diagnostics. The view is read-only by construction and is not an interface table; consumers should not issue DML against it.

Underlying Base Objects

The view is defined over two documented base objects, both accessed through APPS synonyms: OKC_CONDITION_LINES_B, the transactional base table holding condition line definitions, and OKC_CONDITION_LINES_TL, the translation table carrying the language-specific DESCRIPTION column. The join predicate links the two on CNLB.ID = CNLT.ID and is additionally filtered by CNLT.LANGUAGE = USERENV('LANG'), so only the row matching the caller's current language environment is returned. A further predicate restricts results to CNLB.CNL_TYPE = 'CEX', meaning the view is a specialized projection rather than an unfiltered passthrough of the condition lines table. This is why querying the view returns only counter-expression lines and not every condition line stored in the underlying entity table.

Key Columns

  • ROW_ID — the oracle ROWID of the base row, useful for locating the underlying record.
  • ID — primary identifier of the condition line; joins back to OKC_CONDITION_LINES_B and OKC_CONDITION_LINES_TL.
  • OBJECT_VERSION_NUMBER — optimistic locking version stamp from the base table.
  • SFWT_FLAG — flag sourced from the translation table.
  • CNH_ID — header identifier linking the line to its parent condition header.
  • LEFT_CTR_MASTER_ID / RIGHT_CTR_MASTER_ID — the master identifiers for the left and right operands of the counter-expression. This is the column family referenced by the search term "left_ctr_master_id"; LEFT_CTR_MASTER_ID identifies the contract master associated with the left side of the expression.
  • LEFT_COUNTER_ID / RIGHT_COUNTER_ID — the specific counter definitions referenced on each side of the expression.
  • DNZ_CHR_ID — the contract (document) identifier for the row.
  • SORTSEQ — ordering sequence used to reconstruct the expression in evaluation order.
  • DESCRIPTION — language-resolved text from the translation table.
  • LEFT_PARENTHESIS, RELATIONAL_OPERATOR, RIGHT_PARENTHESIS, LOGICAL_OPERATOR — the syntactical elements that encode the expression's operator precedence and grouping.
  • TOLERANCE, START_AT, RIGHT_OPERAND — evaluation parameters controlling comparison tolerance, the starting point of evaluation, and the right-hand operand value.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard EBS descriptive flexfield columns.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns.

Common Use Cases and Queries

Typical uses include reconstructing counter-expression logic for a contract, exporting condition definitions to external rating or integration layers, and troubleshooting why a particular conditional term evaluated as it did. Because sorting and grouping columns are exposed, report authors can sequence the operators back into readable logical statements.

Retrieve all counter expressions for a contract:

  • SELECT id, cnh_id, dnz_chr_id, left_ctr_master_id, right_ctr_master_id, sortseq, description FROM okc_cnl_counter_expr_v WHERE dnz_chr_id = :p_chr_id ORDER BY sortseq;

Inspect the operators and operands of a specific line:

  • SELECT id, left_parenthesis, relational_operator, right_operand, right_parenthesis, logical_operator, tolerance FROM okc_cnl_counter_expr_v WHERE id = :p_line_id;

Find lines by master identifier on either side:

  • SELECT id, dnz_chr_id, left_ctr_master_id, right_ctr_master_id FROM okc_cnl_counter_expr_v WHERE left_ctr_master_id = :p_master_id OR right_ctr_master_id = :p_master_id;

Join to the condition header for header-level context using CNH_ID, and always constrain by DNZ_CHR_ID or ID where possible, since the view performs a language join and a type filter on every access.