Search Results okl_sys_acct_opts_pk

Overview

The OKL_SYS_ACCT_OPTS table is a configuration-level data object within the Oracle E-Business Suite (EBS) Leasing and Finance Management (OKL) module. Its documented purpose is to store system accounting options — the parameter definitions that govern how the leasing and finance application derives, defaults, and posts accounting entries for lease and financing contracts. Rather than holding transactional accounting distributions, this table captures the setup decisions that shape accounting behavior across the OKL application.

The supplied metadata records the primary key as OKL_SYS_ACCT_OPTS_PK on the ID column, and notes a Data Vault classification (heuristic, mined from foreign key structure) of standalone. Phrased as a modeling suggestion, this means OKL_SYS_ACCT_OPTS behaves as a hub-like or reference/setup entity with no documented foreign key dependencies radiating from it. Because the documentation lists no foreign keys to or from this table, it should be modelled as an independent reference structure rather than as a link or a dependent satellite. The metadata also states the object is "Not implemented in this database," indicating that in the sampled ETRM environment the table is either unused, unseeded, or absent, so any reliance on it should be validated against the specific installation.

Key Information Stored

The available metadata is deliberately minimal and documents only a small number of structural facts. The following points reflect what is actually documented:

• ID — the surrogate primary key column, enforced by the OKL_SYS_ACCT_OPTS_PK constraint. It provides a system-generated unique identifier for each accounting-options record.
• Primary key constraint (OKL_SYS_ACCT_OPTS_PK) — the only unique index documented. No separate business-key unique index is described in the metadata.

Because the excerpt does not enumerate the descriptive accounting-option columns, the precise business attributes — such as GL account derivation sources, default accounting rule identifiers, and posting flags — cannot be confirmed from the documentation provided. In a standard OKL implementation, a system accounting options table of this nature typically holds setup identifiers that map lease accounting events to general ledger accounts and accounting rules, together with effective-dating and enabled/disabled indicators. Any column-level mapping should be confirmed directly against the installed data dictionary (for example, ALL_TAB_COLUMNS) before use. The metadata defines the surrogate key (ID) as the authoritative identifier; no alternate business key is documented.

Common Use Cases and Queries

As a setup table, OKL_SYS_ACCT_OPTS is consulted when diagnosing how the leasing application selects accounting options during contract booking or accounting generation. Because the metadata reports the table as not implemented in the reference database, the first practical step in any investigation is confirming whether the object exists and is populated in the target instance.

• Existence and population check: query ALL_TABLES / ALL_TAB_COLUMNS for OKL_SYS_ACCT_OPTS, then SELECT COUNT(*) FROM OKL_SYS_ACCT_OPTS; to determine whether accounting options are seeded.
• Option retrieval by key: SELECT ID FROM OKL_SYS_ACCT_OPTS WHERE ID = :p_id; using the primary key constraint OKL_SYS_ACCT_OPTS_PK.
• Setup audit and reporting: reconcile configured accounting options against expected GL account derivation rules, typically joining to GL code combination views once the descriptive columns are identified.
• Migration and upgrade validation: verify that system accounting options carried forward between environments retain referential integrity against each row's surrogate ID.

Related Objects

The mined relationship data classifies OKL_SYS_ACCT_OPTS as standalone, and no foreign keys are documented in the provided metadata. Consequently, no documented join columns can be asserted with certainty. Related objects to review in a standard OKL implementation include other OKL system options and accounting setup tables, the OKL accounting generation and posting APIs, and the GL interface and code combination tables that consume the derived accounting. Because the metadata provides no confirmed foreign key targets, these associations should be treated as areas for investigation rather than as documented relationships, and all joins should be validated against the actual ETRM data dictionary for the specific EBS 12.1.1 or 12.2.2 installation.