Search Results okc_k_accesses_h




Overview
Explore in AI Chat

Overview

OKC_K_ACCESSES_H is the history (audit) table for the OKC_ACCESS_SECURITYS entity within the OKC — Contracts Core module of Oracle E-Business Suite. It records the temporal evolution of access-level assignments that govern which users, groups, or resources may interact with a contract or contract line at a given privilege level. In 12.1.1 and 12.2.2 the table resides in the OKC schema and is flagged VALID; it is populated by the Contracts Core access-control layer whenever a secured contract record is created, modified, or re-secured, so that prior states remain queryable independently of the current row in OKC_ACCESS_SECURITYS.

Because the table stores versioned deltas keyed on an immutable identifier plus a version counter, its heuristic Data Vault classification is a satellite — specifically a versioned, historized satellite attached to the OKC_ACCESS_SECURITYS business key. The metadata labels it "standalone," meaning its FK footprint is minimal; in Data Vault terms it would be modeled as a satellite hanging off the OKC_ACCESS_SECURITYS hub (or link, where ACCESS_LEVEL ties a resource to a contract), with MAJOR_VERSION supplying the effectivity ordering. This classification is a modeling suggestion, not a physical constraint; OKC does not implement classic Data Vault structures.

Key Information Stored

The documented physical schema carries thirteen columns, of which the following are the most significant for reporting and integration. Note that MAJOR_VERSION participates in the primary key but is often described alongside version number semantics, so it is listed with that caveat.

  • ID — surrogate identifier for the access record; first component of the primary key OKC_K_ACCESSES_H_PK and of unique index OKC_K_ACCESSES_H_U1, and the de facto foreign reference back to the current OKC_ACCESS_SECURITYS row.
  • MAJOR_VERSION — monotonic version counter; second PK component. Together with ID it distinguishes successive historical states of the same access assignment.
  • SECURITY_GROUP_ID — the only documented foreign key; references FND_SECURITY_GROUPS and drives multi-org / security-group partitioning of visibility.
  • CHR_ID — the contract header or contract identifier to which the access grant applies, linking access policy to a specific contractual instrument.
  • GROUP_ID — the group (role, party, or organizational unit) being granted or revoked access.
  • RESOURCE_ID — the protected resource (contract, document, or folder) against which the access level is asserted.
  • ACCESS_LEVEL — the privilege value itself (for example view, update, or administrative rights), the operative payload of each historical row.
  • OBJECT_VERSION_NUMBER — optimistic-locking token used by the Oracle Applications Framework to detect concurrent updates.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO columns providing audit provenance for each version.

ID and MAJOR_VERSION together form both the primary key and the unique business-key candidate OKC_K_ACCESSES_H_U1; no other unique constraint is documented, so business uniqueness derives from the combination of ID plus version rather than from any single business attribute.

Common Use Cases and Queries

Typical usage centers on audit reconstruction, security troubleshooting, and point-in-time reporting. A frequent pattern retrieves the full version chain for one access record:

  • SELECT id, major_version, chr_id, group_id, resource_id, access_level, last_updated_by, last_update_date FROM okc.okc_k_accesses_h WHERE id = :p_id ORDER BY major_version;
  • Point-in-time reconstruction joins the history table to OKC_ACCESS_SECURITYS to compare current versus prior ACCESS_LEVEL values and surface drifted privileges.
  • Security-group reporting filters on SECURITY_GROUP_ID to confine results to the operating unit or group context, joining FND_SECURITY_GROUPS for descriptive names.
  • Change-frequency or "who granted what, when" analysis groups by GROUP_ID and CREATED_BY over CREATION_DATE windows, useful for SOX and internal-audit evidence packs.
  • Concurrent-update diagnostics compare OBJECT_VERSION_NUMBER across adjacent MAJOR_VERSION rows to detect lost-update conditions.

Related Objects

  • OKC_ACCESS_SECURITYS — the current-state parent entity for which OKC_K_ACCESSES_H is the documented history table; join on ID.
  • OKC_K_ACCESSES_H_PK / OKC_K_ACCESSES_H_U1 — primary key and unique index (ID, MAJOR_VERSION) enforcing version integrity.
  • FND_SECURITY_GROUPS — referenced via SECURITY_GROUP_ID; the sole documented foreign key target.
  • OKC_K_HEADERS / OKC_K_LINES — contract header and line entities functionally referenced through CHR_ID and RESOURCE_ID.
  • FND_USER — resolves CREATED_BY and LAST_UPDATED_BY to named audit actors.
  • OKC_CONTRACT_SECURITY_PVT and related OKC PL/SQL APIs — application logic that writes access changes and, by extension, their historical rows.