Search Results oks_reprocessing_n1

Overview

The OKS.OKS_REPROCESSING table is a Service Contracts (OKS) transactional staging and audit table that records the outcome of Service Order lines processed from the Order Capture queue. It resides in the APPS schema's OKS product, is classified as VALID in Oracle E-Business Suite 12.1.1 and 12.2.2, and is stored in the APPS_TS_TX_DATA tablespace with a PCT Free of 10. The table serves as the interface between order capture activity and Service Contracts creation: when the "Service Contracts Order Capture" concurrent program is executed, relevant order line attributes are written here, and the "Order Reprocessing" concurrent program subsequently consumes those rows to instantiate contracts. Successfully interfaced lines capture the resulting contract details; failed lines retain diagnostic error text so users can correct and resubmit them through the Service Order Reprocessing form.

Based on the data vault classification heuristic derived from its foreign key structure, OKS_REPROCESSING is described as standalone. As a modeling suggestion, its primary key on ID and its multiple foreign-key-style references to order and contract entities position it as a link-style record — an associative artifact capturing the event of an order line being processed into a contract — rather than a pure hub or satellite.

Key Information Stored

The table contains 19 documented columns. The most operationally significant include:

• ID — surrogate primary key (OKS_REPROCESSING_PK) and the column behind the unique index OKS_REPROCESSING_U1, which serves as the principal business-key candidate.
• ORDER_ID and ORDER_LINE_ID — identify the source order and its line.
• ORDER_NUMBER — human-readable order reference.
• CONTRACT_ID and CONTRACT_LINE_ID — the contract and contract line generated when processing succeeds.
• SUBLINE_ID — references a subline where applicable.
• ERROR_TEXT — the textual cause of failure, used to remediate and resubmit.
• SUCCESS_FLAG — status indicator: 'S' (success), 'E' (error), 'N' (new line entered via Reprocess Order form), 'R' (submitted for processing).
• SOURCE_FLAG — indicates whether the line originated from Order Capture or was entered manually.
• REPROCESS_YN — flags whether the line is eligible for reprocessing.
• CONC_REQUEST_ID — ties the row to the concurrent request that created it.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS for multi-tenant data isolation.
• OBJECT_VERSION_NUMBER, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns.

Common Use Cases and Queries

Typical scenarios include monitoring interface throughput, diagnosing failed order lines, and reconciling contracts to their originating orders.

• Identify open errors for remediation: SELECT id, order_number, error_text FROM oks.oks_reprocessing WHERE success_flag = 'E';
• Measure success rate by source: SELECT source_flag, success_flag, COUNT(*) FROM oks.oks_reprocessing GROUP BY source_flag, success_flag;
• Trace a contract back to its order: SELECT order_number, contract_id, contract_line_id FROM oks.oks_reprocessing WHERE contract_id = :contract_id;
• Locate rows awaiting reprocessing: SELECT id, order_line_id FROM oks.oks_reprocessing WHERE reprocess_yn = 'Y' AND success_flag = 'R';

Related Objects

The most significant related objects, based on documented relationships and functional context, include:

• FND_SECURITY_GROUPS — referenced via SECURITY_GROUP_ID.
• OE_ORDER_HEADERS_ALL / OE_ORDER_LINES_ALL — source of ORDER_ID and ORDER_LINE_ID.
• OKS_HEADERS / OKS_K_LINES — target contracts and contract lines referenced by CONTRACT_ID and CONTRACT_LINE_ID.
• OKS_REPROCESSING_* indexes — OKS_REPROCESSING_U1 (unique on ID) and OKS_REPROCESSING_N1 (nonunique).
• FND_CONCURRENT_REQUESTS — linked through CONC_REQUEST_ID for request-level tracing.