Search Results sbt_code




Overview
Explore in AI Chat

Overview

The view APPS.OKC_SUBJECT_GROUPS_V is a reporting and integration object within the OKC – Contracts Core product of Oracle E-Business Suite, available in releases 12.1.1 and 12.2.2. It exposes the contents of the contract subject group mapping table in a stable, query-friendly form. In the Contracts Core data model, subject groups allow related subjects of a contract (for example, parties, clauses, or other subject types) to be grouped together so that shared behavior, defaults, or processing rules can be applied to the group rather than to each subject individually. The view is the only documented layer between external consumers and the physical OKC_SUBJECT_GROUPS table, so it serves as the supported read surface for Forms personalizations, concurrent program extracts, OAF pages, and third-party integrations that need to resolve subject group relationships.

The view is registered as VALID and is owned by the APPS schema, which is consistent with the standard EBS convention of exposing application data through APPS-owned views defined over the same-named base table.

Underlying Base Objects

The documented base object is the synonym OKC_SUBJECT_GROUPS, which resolves to the physical table of the same name in the OKC schema. The view definition is a straight projection with no joins, filters, or aggregations:

  • OKC_SUBJECT_GROUPS_V selects all business and WHO columns from OKC_SUBJECT_GROUPS.
  • SGRB.ROWID is aliased to ROW_ID, providing an addressable identifier even though no single surrogate key column is exposed.
  • Because the view is a one-to-one projection, row counts and cardinality match the underlying table exactly, and no row can be missing or duplicated as a result of the view.

As with most APPS views, DML against the view is not the intended pattern; changes to subject group definitions are made through the Contracts Core application or the base table by authorized processes. The view should be treated as read-only by reporting and integration components.

Key Columns

The columns exposed by the view map directly to the base table:

  • ROW_ID — the ROWID of the underlying row, useful as a unique handle for a subject group mapping when no natural key is convenient.
  • SBT_CODE — the subject code, identifying the subject (or subject type) that participates in the group. This is the column most frequently referenced when searching for a specific subject, and it is the object of the “sbt_code” search term.
  • SBT_CODE_GROUPED — the subject code of the group to which SBT_CODE belongs. Together, the SBT_CODE/SBT_CODE_GROUPED pair defines the grouping relationship and is the primary axis for querying the view.
  • OBJECT_VERSION_NUMBER — optimistic locking version used by the Contracts Core framework; useful for detecting concurrent modifications during integration loads.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns, supporting audit reporting and incremental extraction based on LAST_UPDATE_DATE.

Common Use Cases and Queries

Typical scenarios include resolving all subjects in a group, finding the group for a given subject, and incremental extracts for downstream systems. Example statements follow.

List every subject belonging to a specific group:

SELECT sbt_code, sbt_code_grouped
FROM   okc_subject_groups_v
WHERE  sbt_code_grouped = :p_group_code;

Find the group a particular subject is assigned to:

SELECT sbt_code_grouped
FROM   okc_subject_groups_v
WHERE  sbt_code = :p_sbt_code;

Incremental extract using the WHO audit columns:

SELECT sbt_code, sbt_code_grouped,
       object_version_number, last_update_date
FROM   okc_subject_groups_v
WHERE  last_update_date >= :p_since_date;

Because the view is unaggregated, callers should apply their own DISTINCT or grouping logic when a one-row-per-group result is required, and should join to subject definition tables or Contracts Core subject views when descriptive attributes of the subject or group are needed.