Search Results okl_rbk_selected_contract_pk

Overview

The OKL_RBK_SELECTED_CONTRACT table is a transaction-staging object within the Oracle Lease and Finance Management (OKL) module. Its documented purpose is to store the set of contracts that a user has selected for the rebooking process. Rebooking in OKL is the operation by which a lease or loan contract is re-created, re-priced, or re-termed under a new or revised agreement, and this table captures the working set of candidate contracts that feed that operation before the rebooking program executes the actual contract transformation.

The object resides in the OKL schema and is marked VALID in the ETRM catalogue. The heuristic Data Vault classification mined from its foreign-key structure is standalone, which suggests it is best modelled as a standalone hub-like entity rather than a link or satellite. In practice the table behaves as a transient, batch-scoped staging store: rows are tied to a named concurrent request and are meaningful only for the lifetime of that request, after which they are typically purged or left as an audit trail of the contracts that were submitted for rebooking.

Key Information Stored

The table is documented with 31 physical columns. The most significant are:

• ID – the surrogate primary key, enforced by OKL_RBK_SELECTED_CONTRACT_PK and also the single-column unique index OKL_RBK_SELECTED_CONTRACT__U1. Uniqueness is technical, not business-derived.
• REQUEST_NAME – identifies the concurrent program run (or user session) that populated the selection, allowing multiple selections to coexist.
• KHR_ID – the foreign key to OKL_PRTFL_CNTRCTS_B, tying each staging row to the underlying contract/portfolio record that is the true business key.
• CONTRACT_NUMBER and CONTRACT_DESCRIPTION – denormalised business identifiers displayed to the user in the rebooking selection screen.
• KLE_ID – the lease identifier, linking the row to the lease-line-level entities used during rebooking.
• TRANSACTION_ID and TRANSACTION_DATE – the rebooking transaction context and the date the selection was recorded.
• SELECTED_FLAG – the user-controlled indicator marking which candidates are included in the run.
• STATUS – the processing state of each selected contract as rebooking proceeds (for example, pending, processed, or errored).
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 – the standard Oracle EBS descriptive-flexfield extension columns used to carry client-specific selection criteria.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – the mandatory Who-column audit set.

Common Use Cases and Queries

Typical usage centres on the rebooking concurrent program and on operational reporting to confirm which contracts were submitted, and with what outcome. Queries almost always filter by REQUEST_NAME or KHR_ID:

• Retrieve all contracts staged by a specific run: SELECT CONTRACT_NUMBER, KHR_ID, SELECTED_FLAG, STATUS FROM OKL_RBK_SELECTED_CONTRACT WHERE REQUEST_NAME = :p_request;
• Confirm which candidates were actually actioned: SELECT * FROM OKL_RBK_SELECTED_CONTRACT WHERE REQUEST_NAME = :p_request AND SELECTED_FLAG = 'Y';
• Diagnose failures by inspecting rows where STATUS indicates an error condition for a given TRANSACTION_ID.
• Feed a rebooking audit report joining the staging rows back to OKL_PRTFL_CNTRCTS_B to obtain portfolio and customer detail.
• Clean-up scripts that purge rows by CREATION_DATE after the rebooking transaction has been confirmed in the production lease tables.

Related Objects

The documented foreign-key relationship defines the primary linkage; the remaining objects are the natural functional neighbours in the rebooking flow.

• OKL_PRTFL_CNTRCTS_B – joined on KHR_ID; the master contract table supplying the authoritative contract identity behind each selected row.
• OKL_PRTFL_CNTRCTS_TL – provides translated contract names and descriptions for reporting joins through KHR_ID.
• OKL_K_LEASES / OKL_K_LINES family – lease-level entities referenced through KLE_ID during line-level rebooking.
• OKL_RBK_* concurrent programs and rebooking APIs – the programs that read SELECTED_FLAG = 'Y' rows and write back updated STATUS values.
• FND_CONCURRENT_REQUESTS – relates through REQUEST_NAME to give request-level context, submission user, and completion status.

Because the table is standalone at the Data Vault level, it carries no downstream child tables of its own; its lifecycle is entirely driven by the rebooking programs and by maintenance purges.