Search Results oki_seq_growth_rate




Overview

OKI_SEQ_GROWTH_RATE is a table within the OKI (Contracts Intelligence) product family of Oracle E-Business Suite. The OKI module is documented as obsolete in ETRM metadata for both release 12.1.1 and 12.2.2, and the table is explicitly marked as "Not implemented in this database" in the reference environment. Despite this status, the object remains part of the historical schema footprint delivered by the OKI product, and it appears in data dictionary extracts, dependency reports, and customization audits performed against EBS instances upgraded from earlier releases.

Functionally, the table stores period-over-period sequence growth rate measurements derived from contract and service coverage data. The presence of paired current and previous amount columns, a summary build date, and period attributes indicates that OKI used this object as a pre-aggregated analytical summary rather than as an operational transaction table. Under the heuristic Data Vault classification mined from the foreign key structure, the table is modeled as a standalone table — it neither acts as a hub with dependent satellites nor as a link resolving many-to-many relationships. This classification is a modeling suggestion only; in practice the table behaves as a denormalized fact-style summary whose grain is defined by the unique index.

Key Information Stored

The table contains 20 documented columns. The most significant fall into three groups: period context, party and organization context, and measured amounts.

The documented unique index OKI_SEQ_GROWTH_RATE_U1 defines the business key over PERIOD_NAME, PERIOD_SET_NAME, PERIOD_TYPE, SUMMARY_BUILD_DATE, AUTHORING_ORG_ID, SEQ_GRW_RATE_CODE, SCS_CODE, CUSTOMER_PARTY_ID, and PRODUCT_CATEGORY_CODE. No surrogate primary key column is documented in the schema listing.

Common Use Cases and Queries

Because the table is not implemented in current environments, the primary practical uses are migration analysis, custom reporting reconstruction, and dependency assessment during upgrades. A representative query computes growth between snapshots for a given customer and product category:

  • Period-by-period growth: select PERIOD_NAME, CUSTOMER_NAME, PRODUCT_CATEGORY_CODE, and the ratio of CURR_BASE_CONTRACT_AMOUNT to PREV_BASE_CONTRACT_AMOUNT to derive the effective growth percentage.
  • Snapshot comparison: filter on SUMMARY_BUILD_DATE to reproduce the exact state of a period as seen by a prior OKI summary run.
  • Reconciliation: join CURR_SOB_CONTRACT_AMOUNT against ledger balances from GL or against contract headers in OKC to validate that OKI summarization agrees with transaction-level data.
  • Lineage auditing: query REQUEST_ID and PROGRAM_ID to trace which concurrent program and application produced a given summary row.

Related Objects

The only documented foreign key from OKI_SEQ_GROWTH_RATE is SECURITY_GROUP_ID, which references FND_SECURITY_GROUPS. This ties the table into the standard EBS row-level security framework and means any query against the table should respect the security group context of the session. Additional objects that logically relate to the table, based on its column semantics rather than documented constraints, include:

  • FND_SECURITY_GROUPS — the sole referenced parent, via SECURITY_GROUP_ID.
  • FND_CONCURRENT_REQUESTS — joinable on REQUEST_ID to identify the summarizing concurrent request and its completion status.
  • FND_APPLICATION — joinable on PROGRAM_APPLICATION_ID to resolve the owning application short name.
  • FND_CONCURRENT_PROGRAMS — joinable on PROGRAM_ID and PROGRAM_APPLICATION_ID for program naming.
  • GL_PERIODS or the period set tables — joinable on PERIOD_NAME and PERIOD_SET_NAME to resolve period start and end dates.
  • HZ_PARTIES — joinable on CUSTOMER_PARTY_ID to obtain the full trading partner record behind CUSTOMER_NAME.
  • OKC_CONTRACTS — the contract repository whose amounts the summary is derived from; no FK is documented, making the relationship implicit.

Because the table is obsolete and unimplemented, integrators should confirm its physical presence with a data dictionary query against ALL_TABLES before referencing it in custom code, and should favor current OKC and Contracts Intelligence substitutes where available.