Search Results oks_reprocessing_pk

Overview

The OKS_REPROCESSING table is a Service Contracts (OKS) module object in Oracle E-Business Suite 12.1.1 and 12.2.2. It functions as a staging and audit registry for reprocessing operations executed against service contract orders, order lines, contract headers, and contract lines. When Service Contracts processes contract authoring, order submission, or concurrent program activity, records that fail during initial execution can be flagged for reprocessing; OKS_REPROCESSING captures the offending identifiers, the diagnostic error text, the outcome flag, and the concurrent request that drove the attempt. In effect, the table provides operators with a durable worklist of items that require a retry or manual intervention.

From a Data Vault modeling perspective, the ETRM metadata classifies this object as standalone, meaning it does not act as a dependent child in a classic hub-and-satellite pattern but is better modeled as an independent hub or a degenerate transaction record in its own right. The suggested interpretation is a standalone hub keyed on the reprocessing event, with the reprocessing metadata treated as descriptive attributes.

Key Information Stored

The physical schema documents 19 columns. The most operationally significant are:

• ID — the surrogate primary key, enforced by the unique index OKS_REPROCESSING_PK and repeated as a business-key candidate in unique index OKS_REPROCESSING_U1.
• ORDER_ID and ORDER_LINE_ID — identify the service contract order and line that failed or are pending reprocessing.
• CONTRACT_ID, CONTRACT_LINE_ID, and SUBLINE_ID — the corresponding service contract header, line, and subline context.
• ORDER_NUMBER — a human-readable order reference for reporting without requiring a join.
• ERROR_TEXT — the diagnostic message generated during the failed processing attempt.
• SUCCESS_FLAG and REPROCESS_YN — flags indicating whether the reprocessing attempt succeeded and whether the row remains eligible for retry.
• SOURCE_FLAG — distinguishes the originating process or channel that generated the reprocessing entry.
• CONC_REQUEST_ID — links the entry to the concurrent request (FND_CONCURRENT_REQUESTS) that performed the attempt.
• OBJECT_VERSION_NUMBER — the optimistic locking token used by the Oracle ADF/BC4J layer.
• Standard audit columns CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN, plus SECURITY_GROUP_ID for multi-tenant security.

Common Use Cases and Queries

Support teams query OKS_REPROCESSING to triage contract orders that failed to complete. Typical patterns include:

• Listing all outstanding failures: SELECT ORDER_NUMBER, ERROR_TEXT FROM OKS_REPROCESSING WHERE SUCCESS_FLAG = 'N' AND REPROCESS_YN = 'Y';
• Auditing which concurrent request produced a failure by joining CONC_REQUEST_ID to FND_CONCURRENT_REQUESTS.
• Grouping errors to identify systemic issues: SELECT SOURCE_FLAG, ERROR_TEXT, COUNT(*) FROM OKS_REPROCESSING GROUP BY SOURCE_FLAG, ERROR_TEXT;
• Trend reporting by creation date to measure contract processing reliability over time.
• Tracing a contract order end-to-end by joining ORDER_ID and CONTRACT_ID to OKC headers and lines.

Related Objects

• FND_SECURITY_GROUPS — referenced via OKS_REPROCESSING.SECURITY_GROUP_ID.
• FND_CONCURRENT_REQUESTS — joined through CONC_REQUEST_ID.
• OKC_CONTRACTS (or OKC_K_HEADERS_B) — via CONTRACT_ID.
• OKC_LINES / OKC_K_LINES_B — via CONTRACT_LINE_ID and SUBLINE_ID.
• OE_ORDER_HEADERS_ALL and OE_ORDER_LINES_ALL — via ORDER_ID and ORDER_LINE_ID where Service Contracts order data derives from Order Management.
• OKS_ENTITLEMENTS and OKS_CONTRACTS_ALL — common downstream contract objects sharing the OKS schema.
• OKS Service Contracts concurrent programs that populate SUCCESS_FLAG after retry.